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

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

[eregontp]

Issue #17146 has been reported by Eregon (Benoit Daloze).

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

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

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

[ko1]

Issue #17146 has been updated by ko1 (Koichi Sasada).


> I guess old Thread::Queue implemented in Ruby did not have this bug.


`require "thread"; q=Queue.new.freeze; q.push 1` works without error from Ruby 1.6.0.
Surprisingly before 1.6.0 there is no `Queue#freeze`.

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

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

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

[merch-redmine]

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/

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

[ko1]

Issue #17146 has been updated by ko1 (Koichi Sasada).


It seems "what is freeze mean" discussion.

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

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

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

[eregontp]

Issue #17146 has been updated by Eregon (Benoit Daloze).


ko1 (Koichi Sasada) wrote in #note-1:
> `require "thread"; q=Queue.new.freeze; q.push 1` works without error from Ruby 1.6.0.

Ah, yes, because it's not deeply frozen:
https://github.com/ruby/ruby/blob/23ccbdf52188b78427f41d75b1a4b81959ac9876/lib/thread.rb#L145

At least #deep_freeze on Queue should prevent #push/#pop.
But I think #freeze should prevent #push/#pop too, just like for every other core collection.

jeremyevans0 (Jeremy Evans) wrote in #note-2:
> 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.

One could still use Queue#empty? and Queue#size.
I think freezing a Queue should be similar to Queue#close, but also prevent #pop.
Many objects become severely limited when deeply frozen. I don't think Queue should be a special case.

> 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.

What if it's a non-shareable object?
It seems unacceptable to copy the object in that case, because how would we know if it is the same or different Ractor that will Queue#pop that element?

So IMHO the simplest thing makes sense: Queue#freeze prevents modifications to the Queue (which is the general contract of #freeze for collections). A Queue cannot be copied by Ractor (neither by #dup nor Marshal.dump). The Queue can be frozen but then indeed is of limited value.

Ractor communicate via their internal channels.
Queues don't work with Ractor (i.e., cannot be used to communicate between Ractors), and they cannot for compatibility (would copy non-shareable elements, which would be incompatible).

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

AFAIK no other class undefines #freeze, that seems unfriendly.
I don't see any real-world motivation to prevent freezing a Queue (and it would be inconsistent).
So I think this is a plain bug and we should fix it.

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

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

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

[ko1]

Issue #17146 has been updated by ko1 (Koichi Sasada).

Status changed from Open to Feedback

At last dev-meeting we skipped this issue because it is difficult, but no benefit to change the current behavior.

BTW

> AFAIK no other class undefines #freeze, that seems unfriendly.

`ENV.freeze` raises an error (`freeze': cannot freeze ENV (TypeError)).

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

* Author: Eregon (Benoit Daloze)
* Status: Feedback
* 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/

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

[Eregon (Benoit Daloze)]

Issue #17146 has been updated by Eregon (Benoit Daloze).

Status changed from Closed to Open

Why was this closed?

I think there is only one rational answer here:
`Queue#freeze` should prevent mutations to the Queue just like for Array/Hash/etc.

There is no other "nested object" (i.e., the queue contents) exposed to user code, so it would just be weird if `Queue#deep_freeze` would actually prevent mutation of the queue but `Queue#freeze` does not.

"deep freeze" should be equivalent to calling `freeze` on each object in an object graph, this can't work if `Queue#freeze` doesn't prevent mutations.

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

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

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

[jeremyevans0 (Jeremy Evans)]

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


Eregon (Benoit Daloze) wrote in #note-7:
> Why was this closed?

Because there was no feedback after the last message from @ko1, and it was decided at the developer meeting last year that there was no benefit to changing the behavior.

You are welcome to bring this issue up again at another developer meeting.  However, if the same conclusion is reached, I think this issue should be closed again.

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

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

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

[Eregon (Benoit Daloze)]

Issue #17146 has been updated by Eregon (Benoit Daloze).


OK, that `no benefit to changing the behavior.` was not reported here but I guess it's in the dev meeting log.

Benefit is consistency and being able to design deep freezing/immutable without making an exception for Queue.
Every time deep freezing/immutable comes up, this comes up as well as a problem.

I argue the current behavior is useful to nobody, and it's highly inconsistent, i.e., let's fix it.

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

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

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

[Eregon (Benoit Daloze)]

Issue #17146 has been updated by Eregon (Benoit Daloze).


(an alternative would be to have some other way to freeze the Queue for the purpose of `deep_freeze`/`Immutable`, but I see no value to that, the way is called `freeze` and it already works for most objects).

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

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

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

[jeremyevans0 (Jeremy Evans)]

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


Eregon (Benoit Daloze) wrote in #note-9:
> OK, that `no benefit to changing the behavior.` was not reported here but I guess it's in the dev meeting log.

ko1 (Koichi Sasada) wrote in #note-5:
> At last dev-meeting we skipped this issue because it is difficult, but no benefit to change the current behavior.


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

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

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

[Eregon (Benoit Daloze)]

Issue #17146 has been updated by Eregon (Benoit Daloze).


Indeed, sorry, I missed that somehow.

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

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

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

[ioquatix (Samuel Williams)]

Issue #17146 has been updated by ioquatix (Samuel Williams).


> I think there is only one rational answer here: Queue#freeze should prevent mutations to the Queue just like for Array/Hash/etc.

I agree with this for consistency reasons. Anyone who is freezing a queue and expecting it to work has buggy code.

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

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

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

[matz (Yukihiro Matsumoto) via ruby-core]

Issue #17146 has been updated by matz (Yukihiro Matsumoto).


Since frozen `queue` is meaningless, if you care about consistency, we should prohibit `freeze` queues, like `ENV`.

Matz.


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

* 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/
 ______________________________________________
 ruby-core mailing list -- ruby-core@ml.ruby-lang.org
 To unsubscribe send an email to ruby-core-leave@ml.ruby-lang.org
 ruby-core info -- https://ml.ruby-lang.org/mailman3/postorius/lists/ruby-core.ml.ruby-lang.org/

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

[mame (Yusuke Endoh) via ruby-core]

Issue #17146 has been updated by mame (Yusuke Endoh).


I would like to add a point that came up during the dev meeting: if a thread is waiting for `Queue#pop`, and another thread freezes the Queue, what should the first thread do? Wait forever? Raise a FrozenError?

To raise a FrozenError, it needs to be told that the Queue was asynchronously frozen by another thread. In other words, `Queue#freeze` needs to wake up the thread waiting for the Queue, which is likely to do more than `#freeze` would normally be expected to do.



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

* 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/
 ______________________________________________
 ruby-core mailing list -- ruby-core@ml.ruby-lang.org
 To unsubscribe send an email to ruby-core-leave@ml.ruby-lang.org
 ruby-core info -- https://ml.ruby-lang.org/mailman3/postorius/lists/ruby-core.ml.ruby-lang.org/

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

[jeremyevans0 (Jeremy Evans) via ruby-core]

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


I submitted a pull request to have `{Queue,SizedQueue}#freeze` raise `TypeError`, as `ENV.freeze` does: https://github.com/ruby/ruby/pull/8515

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

* 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/
 ______________________________________________
 ruby-core mailing list -- ruby-core@ml.ruby-lang.org
 To unsubscribe send an email to ruby-core-leave@ml.ruby-lang.org
 ruby-core info -- https://ml.ruby-lang.org/mailman3/postorius/lists/ruby-core.ml.ruby-lang.org/