When you hit the limit on queued puts you can look outside core.async for something to act as an unbounded buffer, like a list, but that is treating a symptom

Hitting the queued puts limit means you are queueing items faster than you can process them, and an unbounded buffer isn't going to solve that

You may want to look at a sliding buffer or a dropping buffer, which are different policies for handling producing faster than you can consume

A lot of JavaScript callback APIs are problematic in that they don't have a good way to communicate back pressure to slow a producer down for a consumer

I would look at using two channels, one to send lines to be processed down, and one to ack lines as processed

The callback for each line should put! The line on the line channel then read from the ack channel. Maybe that would be take! I don't remember.

Blegh, it doesn't actually look like take! Would do it, so there just may not be a way to do the feedback think

Has anyone written a core.async channel that closed at a certain time, rather than after a duration of time has elapsed?

Would be easy to do with existing Java stuff

making a timeout channel of the delta not sufficient?

If the jvm is paused for an amount of time (e.g. laptop turned off, but other scenarios seem plausible) the timeout doesn’t count the paused time

@donaldball: does GC affect it too?

Do you mean JVM pauses for GC? Frankly I’m not sure.

yeah

AFAICT the java.util.concurrent classes only provide guarantees on the minimum amount of time things will delay

I’m not actually sure the best way to accomplish my goal with the j.u.c stuff, tbqh. Seems like my best bet might be to start a ScheduledThreadPoolExecutor running e.g. every minute, have it check the system time, and send any necessary signals