[ruby-core:72380] [Ruby trunk - Bug #11822] Semantics of Queue#pop after close are wrong

[email@pitr.ch]

Issue #11822 has been updated by Petr Chalupa.


Thank you for explanation. So nil can mean a normal nil pushed to the queue or closed queue, that might be error prone. As Charles mentioned there are many possible behaviors users might want when queue is closed. I would suggest to make this configurable on queue initialization. 

~~~ ruby
Queue.new on_close: nil # pops nil
Queue.new on_close: :poison_pill # pops symbol :poison_pill
CLOSED = Object.new
Queue.new on_close: CLOSED # pops CLOSED
Queue.new on_close: ClosedQueueError # raises exception of supplied class
~~~

Raising exception seems unnecessary to me, since close is normal feature of the queue not an exceptional state (this is subjective though so including in the example too).

----------------------------------------
Bug #11822: Semantics of Queue#pop after close are wrong
https://bugs.ruby-lang.org/issues/11822#change-55670

* Author: Charles Nutter
* Status: Open
* Priority: Normal
* Assignee: Koichi Sasada
* ruby -v: 
* Backport: 2.0.0: UNKNOWN, 2.1: UNKNOWN, 2.2: UNKNOWN
----------------------------------------
Current test/ruby/thread/test_queue.rb test_close has the following assertion that seems wrong to me:

```ruby
  def test_close
    [->{Queue.new}, ->{SizedQueue.new 3}].each do |qcreate|
      q = qcreate.call
      assert_equal false, q.closed?
      q << :something
      assert_equal q, q.close
      assert q.closed?
      assert_raise_with_message(ClosedQueueError, /closed/){q << :nothing}
      assert_equal q.pop, :something  # <<< THIS ONE
      assert_nil q.pop
      assert_nil q.pop
      # non-blocking
      assert_raise_with_message(ThreadError, /queue empty/){q.pop(non_block=true)}
    end
  end
```

Once a queue is closed, I don't think it should ever return a result anymore. The queue should be cleared and pop should always return nil.

In r52691, ko1 states that "deq'ing on closed queue returns nil, always." This test does not match that behavior.



-- 
https://bugs.ruby-lang.org/