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 292E319E0025 for ; Wed, 16 Dec 2015 00:33:55 +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 1D108B5D90A for ; Wed, 16 Dec 2015 01:05:56 +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 E443E18CC7B5 for ; Wed, 16 Dec 2015 01:05:55 +0900 (JST) Received: from [221.186.184.76] (localhost [IPv6:::1]) by neon.ruby-lang.org (Postfix) with ESMTP id 73BF312048B; Wed, 16 Dec 2015 01:05:53 +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 B98DE120454 for ; Wed, 16 Dec 2015 01:05:49 +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=4BaK62FdXBqId0AlhWMrRvUV+9w=; b=SCZrB1hWXb3+peVoxP lxwPBNsjeC1HHEkmqj9mx3hMCDqwwwWbMdNpaf+i0X+MeYpL3+wTwaD1couFAtM4 u5VnYPlHc99YzYCD+AemAwF+xiM0HD/li6V6lf8Hwn/zOSgy8hobsNkXwoW1vh0g 2+4Pe3LDOAT0xYHyemwbw1IMQ= Received: by filter0526p1mdw1.sendgrid.net with SMTP id filter0526p1mdw1.20491.56703A4D8B 2015-12-15 16:05:33.935627284 +0000 UTC Received: from herokuapp.com (ec2-107-20-1-215.compute-1.amazonaws.com [107.20.1.215]) by ismtpd0006p1iad1.sendgrid.net (SG) with ESMTP id SgrHxYFaQpKfo3uhZqxEIA for ; Tue, 15 Dec 2015 16:05:33.933 +0000 (UTC) Date: Tue, 15 Dec 2015 16:05:33 +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: 46856 X-Redmine-Project: ruby-trunk X-Redmine-Issue-Id: 11822 X-Redmine-Issue-Author: headius 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/Ymy4QrNMhiuLXJG8OTL2vJD1yS5M17LABlnnfM+UxL2WRI8CNLs6092v9E4M+l aAispoGMbo/VMR2rBxfPCRS/NdLMW+cmoPIzZm3rurYq6+yt3Sr+eOHZnX4VgYDT16KOo+aQnYJpAu jyYysnL8xLrxSOdW29iaI5uSDhvDFk2HWtFV4LHrOUVO9alyIV9t+9xawA== X-ML-Name: ruby-core X-Mail-Count: 72149 Subject: [ruby-core:72149] [Ruby trunk - Bug #11822] [Open] 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 reported by Charles Nutter. ---------------------------------------- Bug #11822: Semantics of Queue#pop after close are wrong https://bugs.ruby-lang.org/issues/11822 * Author: Charles Nutter * Status: Open * Priority: Normal * Assignee: * 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: 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/