From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-Status: No, score=-4.0 required=3.0 tests=AWL,BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED, SPF_HELO_NONE,SPF_PASS,UNPARSEABLE_RELAY shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from neon.ruby-lang.org (neon.ruby-lang.org [221.186.184.75]) by dcvr.yhbt.net (Postfix) with ESMTP id E8A341F66F for ; Fri, 4 Sep 2020 01:52:22 +0000 (UTC) Received: from neon.ruby-lang.org (localhost [IPv6:::1]) by neon.ruby-lang.org (Postfix) with ESMTP id CDF29120BF0; Fri, 4 Sep 2020 10:51:46 +0900 (JST) Received: from xtrwkhkc.outbound-mail.sendgrid.net (xtrwkhkc.outbound-mail.sendgrid.net [167.89.16.28]) by neon.ruby-lang.org (Postfix) with ESMTPS id EFAF3120BEF for ; Fri, 4 Sep 2020 10:51:44 +0900 (JST) Received: by filterdrecv-p3las1-b89975484-7ckvc with SMTP id filterdrecv-p3las1-b89975484-7ckvc-20-5F519DCE-19 2020-09-04 01:52:14.629255168 +0000 UTC m=+197422.696922862 Received: from herokuapp.com (unknown) by geopod-ismtpd-4-1 (SG) with ESMTP id Cbj8OQKyRRuAadL5wm6o1Q for ; Fri, 04 Sep 2020 01:52:14.360 +0000 (UTC) Date: Fri, 04 Sep 2020 01:52:14 +0000 (UTC) From: merch-redmine@jeremyevans.net Message-ID: References: Mime-Version: 1.0 X-Redmine-MailingListIntegration-Message-Ids: 75746 X-Redmine-Project: ruby-master X-Redmine-Issue-Tracker: Bug X-Redmine-Issue-Id: 17146 X-Redmine-Issue-Author: Eregon X-Redmine-Sender: jeremyevans0 X-Mailer: Redmine X-Redmine-Host: bugs.ruby-lang.org X-Redmine-Site: Ruby Issue Tracking System X-Auto-Response-Suppress: All Auto-Submitted: auto-generated X-SG-EID: =?us-ascii?Q?RVE3t853K5scBhbmJHUzZTFFeVC=2FZSUmHZ0Dc+26wcEi2CTgsF1oz0wTSSxGGN?= =?us-ascii?Q?BInM1yIUOhbdbzsVo3CBPr8oHu7woyQsHRR+WaX?= =?us-ascii?Q?9NP7isxk8Fy=2FU+ADK8gbgj3oqmEt3bVST3U1=2FUX?= =?us-ascii?Q?k82lnq+EXVBWSI8y0Zie9Q6c7vrVe693ZOCuet4?= =?us-ascii?Q?1czC1N+h4J=2F3X=2F+xZHWsjEnh8OQT5oa3PncIRRi?= =?us-ascii?Q?vII=2FaX7UPlMZAtm9o=3D?= To: ruby-core@ruby-lang.org X-ML-Name: ruby-core X-Mail-Count: 99911 Subject: [ruby-core:99911] [Ruby master Bug#17146] Queue operations are allowed after it is frozen X-BeenThere: ruby-core@ruby-lang.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Ruby developers List-Id: Ruby developers List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: ruby-core-bounces@ruby-lang.org Sender: "ruby-core" 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 => # [2] pry(main)> q.freeze => # [3] pry(main)> q << 1 => # [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/