-
-
Notifications
You must be signed in to change notification settings - Fork 88
Description
I think I put off this issue to be addressed later and then forgot.
We haven't decided what should happen when dequeue/wait! is called on a closed queue, or the queue is closed without adding elements while dequeue/wait! is waiting.
It looks like there's a half-baked attempt to clarify the behavior in enqueue/wait!. An undocumented optional argument if-closed specifies whether an error is thrown if the queue is closed (default), or returns a fimeout-val. It is reasonable for dequeue/wait! to adopt the same semantics.
I vaguely remember that there's a complication when I attempted to handle closed queue situation in dequeue/wait! before----the closed situation is triggered even when dequeue/wait! closed the queue itself. Need to check out.
Also, the intended use case of queue closing should be documented. Generally, a specific marker object of "end of the data stream" should be used, rather than marking the EOS by closing the queue. Closing the queue is to guarantee there won't be any unprocessed element remaining in the queue indefinitely.