From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: poffice@blade.nagaokaut.ac.jp Delivered-To: poffice@blade.nagaokaut.ac.jp Received: from kankan.nagaokaut.ac.jp (kankan.nagaokaut.ac.jp [133.44.2.24]) by blade.nagaokaut.ac.jp (Postfix) with ESMTP id A68A619E005C for ; Fri, 18 Dec 2015 14:00:50 +0900 (JST) Received: from voscc.nagaokaut.ac.jp (voscc.nagaokaut.ac.jp [133.44.1.100]) by kankan.nagaokaut.ac.jp (Postfix) with ESMTP id B84D9B5D828 for ; Fri, 18 Dec 2015 14:32:57 +0900 (JST) Received: from neon.ruby-lang.org (neon.ruby-lang.org [221.186.184.75]) by voscc.nagaokaut.ac.jp (Postfix) with ESMTP id 3537F18CC7B6 for ; Fri, 18 Dec 2015 14:32:58 +0900 (JST) Received: from [221.186.184.76] (localhost [IPv6:::1]) by neon.ruby-lang.org (Postfix) with ESMTP id CA8391206C0; Fri, 18 Dec 2015 14:32:56 +0900 (JST) X-Original-To: ruby-core@ruby-lang.org Delivered-To: ruby-core@ruby-lang.org Received: from o2.heroku.sendgrid.net (o2.heroku.sendgrid.net [67.228.50.55]) by neon.ruby-lang.org (Postfix) with ESMTPS id 20D68120696 for ; Fri, 18 Dec 2015 14:32:52 +0900 (JST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sendgrid.me; h=from:to:references:subject:mime-version:content-type:content-transfer-encoding:list-id; s=smtpapi; bh=zQwGfdcEmMKKB5X9SAMurjI8l9I=; b=lEB6Dn4nnCb8PFDvL2 VIbhAPZWFecUGJTkkusIqXffmCKBK1Xh/5QO51yNZxGvho/p64cAn+Yeu8CXxylB eAdwgk6rKjTXptt+VZSrQerX8rRr7r1F9R8iLXeBEEv1TMsB9+otXEad0l+cAhkQ tyiE/Zw1VAAptjX71ePCdjlCU= Received: by filter0509p1mdw1.sendgrid.net with SMTP id filter0509p1mdw1.17908.56739A8110 2015-12-18 05:32:49.263505938 +0000 UTC Received: from herokuapp.com (ec2-54-161-169-90.compute-1.amazonaws.com [54.161.169.90]) by ismtpd0004p1iad1.sendgrid.net (SG) with ESMTP id g8yFu7yyTrqFz1Y2bNvuNw for ; Fri, 18 Dec 2015 05:32:49.239 +0000 (UTC) Date: Fri, 18 Dec 2015 05:32:49 +0000 From: ko1@atdot.net To: ruby-core@ruby-lang.org Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Redmine-MailingListIntegration-Message-Ids: 46952 X-Redmine-Project: ruby-trunk X-Redmine-Issue-Id: 11822 X-Redmine-Issue-Author: headius X-Redmine-Issue-Assignee: ko1 X-Redmine-Sender: ko1 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: ync6xU2WACa70kv/Ymy4QrNMhiuLXJG8OTL2vJD1yS5iwe2hjoqenlZTvNy4iiAoWsDnbCUEUrw+QG dfkJzcMgRLApxZvnDSTOcZuXNctx4GKA3LZTpHeffxFq0b/cG3abwsdG8DyktjAnVGyVBqr8M+al1r lT0zLhCOZnvnbtUUbIsF12mne7nNLZ7rbXhj X-ML-Name: ruby-core X-Mail-Count: 72357 Subject: [ruby-core:72357] [Ruby trunk - Bug #11822] Semantics of Queue#pop after close are wrong 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: , Errors-To: ruby-core-bounces@ruby-lang.org Sender: "ruby-core" Issue #11822 has been updated by Koichi Sasada. Assignee set to Koichi Sasada # Semantics I'm not sure all I can understand, but Queue#close does not remove remaining items as Yura said. (on 2.3) Queue#close is only for simple way for the following code: ```ruby # without Queue#close q = Queue.new 3.times{ Thread.new{ # workers while e = q.pop work_with(e) end } } q.push work1 q.push work2 q.push work3 q.push work4 3.times{ q.push nil } ``` ```ruby # with Queue#close q = Queue.new 3.times{ Thread.new{ # workers while e = q.pop work_with(e) end } } q.push work1 q.push work2 q.push work3 q.push work4 q.close # simplified ``` Suggestions about documentation are welcome. # Atomicity I think it is possible to implement in atomic with appropriate locks. For example, we can make this implementation on pthread libraries. However, such locks can be affect performance, especially on well-optimized lock-free queue implementations such as Java has. I can't decide the problem is critical or not. We have no time for Ruby 2.3 to prove it. So I can remove Queue#close and continue discussion for ruby 2.4 if someone (Charles) says it should be removed. Charles, what do you think? ---------------------------------------- Bug #11822: Semantics of Queue#pop after close are wrong https://bugs.ruby-lang.org/issues/11822#change-55650 * 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/