should the channel have a non-blocking consume.

[dadkins789]

I need a non-blocking channel so I modified tryConsumeOne() to return early on either an empty queue or a closed condition, rather a blocking until a closed condition or an item in the queue. I added an isClosed() property to check if a tryConsumeOne() returns false and I need to check for a channel closed state. Are there other ways to do non-blocking channel reads that I am missing? Also, empty() also blocks on the same conditions as tryConsumeOne().

[s-ludwig]

We could add a poll() method that behaves like your modified version of tryConsumeOne and possibly let it return an enum instead of bool, so that it is possible to distinguish between an closed and empty channel and an open channel with an empty buffer. Doing it separately is always prone to introducing race-conditions.

[dadkins789]

Oops, I see an example of the intended use of tryConsumeOne in listDirectory core/file.d. My implementation of tryConsumeOne will definitely break it. You are using close to terminate a blocking call when no more producer data is forthcoming. I agree a separate function that performs the non-blocking makes sense to prevent breakage of the existing behavior. put is also blocking on a full queue so for symmetry a non blocking put might also be useful. Let me know if you decide to do it. I'll fix my patched implementation to add a poll and revert tryConsumeOne. Thanks for looking at it.