It is currently difficult to reliably distinguish a nil value in a queue from the nil that is returned when a Queue is closed:
n=100_000result=[]t2=Thread.new{n.times{Thread.pass}}# to make things less predictablen.times.countdoq=Queue.newt=Thread.new{q.pop;result<<q.closed?}q<<nilq.closet.joinendputsresult.count(true)# => some number usually > 9990 and < 10000
To be completely sure, one needs a Mutex or wrap/unwrap nil values.
Queue#pop should offer a surefire way to handle closed queues. I propose that an optional block be called in this case:
General use case: using Queue for objects that might be nil.
Why I opened this issue? I am writing a pure-Ruby backport of Ractor (using Thread). I am using Queue for messaging queues. nil can be value sent / received by Ractors (e.g. Ractor.yield). Can also be the final result of a ractor block. I need to store this in Queue.
My concern is same as with timeout: option: we have an "easy" way to do something that works 99%+ of the time, but is not 100% safe. Currently the only 100% way is difficult. People are lazy. We need to give easy 100% solution.