From: ko1@...
Date: 2015-12-19T01:39:53+00:00
Subject: [ruby-core:72372] [Ruby trunk - Bug #11822] Semantics of Queue#pop after close are wrong

Issue #11822 has been updated by Koichi Sasada.


Petr Chalupa wrote:
> Could you clarify for me following cases: What does pop do when called on empty closed queue? What does close do about already blocked threads when it's empty? 
> The documentation does not specifies this.

> What does pop do when called on empty closed queue?

returns nil.

> What does close do about already blocked threads when it's empty? 

I assume 'already blocked threads' are consumer threads.
They are resumed, and get nil.

You can verify with code.

```ruby
q = Queue.new
q.close
p q.pop
```

```ruby
q = Queue.new
Thread.new{
  sleep 1
  q.close
}
p q.pop
```



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

* 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/