+1 for avoiding exceptions but nil can be problematic? Because a closed queue would also return nil for pop. You cannot distinguish if a queue is closed or would just block.
+1 for avoiding exceptions but nil can be problematic? Because a closed queue would also return nil for pop. You cannot distinguish if a queue is closed or would just block.
We could add another keyword argument for the exception value, and have that value returned instead of raising an exception (the keyword argument would default to nil). I'm not sure if it's worth supporting that, but it is a simple approach.
I don't think people want to exit from a while item = queue.pop loop because the queue would block. for (;;) { if (errno != EAGAIN) break; ... } is a C idiom (people often break from a loop on error, except EAGAIN).
Instead of introducing an exception: false argument to have non_block
return nil rather than raise, we can clearly document that a timeout of 0
immediately returns.
The code is refactored a bit to avoid doing a time calculation in
such case.