[#99868] [Ruby master Bug#17144] Tempfile.open { ... } does not unlink the file — eregontp@...
Issue #17144 has been reported by Eregon (Benoit Daloze).
15 messages
2020/09/03
[ruby-core:99999] [Ruby master Bug#17146] Queue operations are allowed after it is frozen
From:
eregontp@...
Date:
2020-09-13 09:25:32 UTC
List:
ruby-core #99999
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/ Unsubscribe: <mailto:[email protected]?subject=unsubscribe> <http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>