[ruby-core:99911] [Ruby master Bug#17146] Queue operations are allowed after it is frozen

[merch-redmine@jeremyevans.net]

Issue #17146 has been updated by jeremyevans0 (Jeremy Evans).


If a Queue cannot push/pop, it is useless.  A Queue doesn't have any operations on that would make sense if you cannot push/pop.  This makes it  different from most freezable objects, where the object is usable read-only in a frozen state.

In relation to Ractor/deep_freeze discussion, if deep_freeze is called on an object that contains a Queue (directly or transitively), and Queue#freeze makes the Queue unusable, it seems very dangerous.  It would be best if Queue was an shareable object whose operations worked across Ractors.  For example, assuming the object was sharable, a push of the object onto the Queue on Ractor A, while Ractor B, C, and D were waiting in Queue#pop, would result in only one of B, C, D popping the object. However, I don't know whether or not that is feasible.

I think the best solution for `Queue#freeze` is `Queue.send(:undef_method, :freeze)`.

----------------------------------------
Bug #17146: Queue operations are allowed after it is frozen
https://bugs.ruby-lang.org/issues/17146#change-87442

* Author: Eregon (Benoit Daloze)
* Status: Open
* Priority: Normal
* ruby -v: ruby 2.6.6p146 (2020-03-31 revision 67876) [x86_64-linux]
* Backport: 2.5: UNKNOWN, 2.6: UNKNOWN, 2.7: UNKNOWN
----------------------------------------
```
[1] pry(main)> q = Queue.new
=> #<Thread::Queue:0x000056263683aee8>
[2] pry(main)> q.freeze
=> #<Thread::Queue:0x000056263683aee8>
[3] pry(main)> q << 1
=> #<Thread::Queue:0x000056263683aee8>
[4] pry(main)> q.pop
=> 1
[5] pry(main)> q.frozen?
=> true
```

Found by @ko1 in https://bugs.ruby-lang.org/issues/17100#note-28

I think it's a bug, since those are clear mutations.
I guess old Thread::Queue implemented in Ruby did not have this bug.



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