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 7ACA819E002D for ; Sat, 19 Dec 2015 23:55:16 +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 9A6B1B5D898 for ; Sun, 20 Dec 2015 00:27:26 +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 5E9B918CC7AF for ; Sun, 20 Dec 2015 00:27:27 +0900 (JST) Received: from [221.186.184.76] (localhost [IPv6:::1]) by neon.ruby-lang.org (Postfix) with ESMTP id B559E1204E8; Sun, 20 Dec 2015 00:27:27 +0900 (JST) X-Original-To: ruby-core@ruby-lang.org Delivered-To: ruby-core@ruby-lang.org Received: from o10.shared.sendgrid.net (o10.shared.sendgrid.net [173.193.132.135]) by neon.ruby-lang.org (Postfix) with ESMTPS id 02EA91204CB for ; Sun, 20 Dec 2015 00:27:23 +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=4+1RiL0gJpfhIlvccK07fbs9dGc=; b=ycnBtChHwltZPxe2LB VFq5aX+rDhkZH3rimVtoMzDMOjveTSNYBKaJW+mMvtz+tsbC0tn/X7gf+zW9mqaI 3gbcBWnaxJD2gi+qw1GxdeqDkjhL9o5rKdth4BBdI921xRPHgUpnvviTIgG5Q3zx 4LqfjFF1e3AI008tHV0wYds1A= Received: by filter0558p1mdw1.sendgrid.net with SMTP id filter0558p1mdw1.16643.567577551B 2015-12-19 15:27:17.150574439 +0000 UTC Received: from herokuapp.com (ec2-54-204-163-65.compute-1.amazonaws.com [54.204.163.65]) by ismtpd0001p1iad1.sendgrid.net (SG) with ESMTP id 2m0uSl3NRniMLCLis2b0gA Sat, 19 Dec 2015 15:27:17.031 +0000 (UTC) Date: Sat, 19 Dec 2015 15:27:16 +0000 From: headius@headius.com 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: 46981 X-Redmine-Project: ruby-trunk X-Redmine-Issue-Id: 11822 X-Redmine-Issue-Author: headius X-Redmine-Issue-Assignee: ko1 X-Redmine-Sender: headius 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/Ymy4QrNMhiuLXJG8OTL2vJD1yS4Pi/DwfaY5bsBeGgQro6YNBHYa551NqUaIk4 kUSzZK69geDX9FjCsn4pimx6VE641ehnO8sVG8e2kENLOu5WPtsdO/DcEHokGyTiGDsDimwfxBcpyy RLPgIjCOuLsL1mLHmCRscRW7X9nNMFLqN4URaQZ6Q3pvyEz/EnNGrkCzGA== X-ML-Name: ruby-core X-Mail-Count: 72386 Subject: [ruby-core:72386] [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 Charles Nutter. Summarizing some discussion with Koichi on #ruby-core: * Current JRuby Queue uses Java's LinkedBlockingQueue and ArrayBlockingQueue, which both are locking implementations. There are lock-free queue implementations on JVM but they do not support blocking. * Performance of the fully-locked impl of Queue from MRI 2.3 appears to be as good or better than JRuby's existing impls based on Java LBQ and ABQ for single and multi-threaded benchmarks. This is likely because the existing impls were also fully locked *and* JRuby had to implement num_waiters separately. * The API proposed for #close, #push, and #pop for 2.3 is accepted by JRuby since there appears to be no performance implication right now. So we should bump this to to Ruby 2.4 to address the inability to check for closed? and pop at the same time, as in Go. I believe that is the only remaining issue. This can go forward in 2.3. For reference, here's what OpenJDK lock-free queues are based upon: http://www.cs.rochester.edu/u/scott/papers/1996_PODC_queues.pdf We may want to add a lock-free queue implementation to either Ruby or concurrent-ruby in the future. ---------------------------------------- Bug #11822: Semantics of Queue#pop after close are wrong https://bugs.ruby-lang.org/issues/11822#change-55674 * 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/