From: headius@...
Date: 2015-12-15T17:52:07+00:00
Subject: [ruby-core:72155] [Ruby trunk - Bug #11822] Semantics of Queue#pop after close are wrong

Issue #11822 has been updated by Charles Nutter.


Also worth noting that java.util.concurrent's BlockingQueue implementations do not support any of the following for the same reasons as above:

* Closing or shutting down a queue
* Notifying all threads waiting on a queue that it is no longer available

The justification is that shutdown semantics for threads waiting on a queue varies too greatly to have a single consistent semantic. Some code will want a "closed" queue to cause all waiters to raise an error, others may want them to all receive a null value, still others will want them to receive a poison pill indicating the queue is done. Basically, the expectation is that if user code sets up threads to wait on a queue, user code should also handle notifying them that the queue is no longer available for use.

I agree.

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

* Author: Charles Nutter
* Status: Open
* Priority: Normal
* Assignee: 
* 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:

  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/