From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS4713 221.184.0.0/13 X-Spam-Status: No, score=-3.2 required=3.0 tests=AWL,BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,RCVD_IN_DNSWL_MED,SPF_PASS,T_RP_MATCHES_RCVD shortcircuit=no autolearn=ham autolearn_force=no version=3.4.0 Received: from neon.ruby-lang.org (neon.ruby-lang.org [221.186.184.75]) by dcvr.yhbt.net (Postfix) with ESMTP id 609A020282 for ; Thu, 22 Jun 2017 07:44:35 +0000 (UTC) Received: from neon.ruby-lang.org (localhost [IPv6:::1]) by neon.ruby-lang.org (Postfix) with ESMTP id 2B8DA120792; Thu, 22 Jun 2017 16:44:33 +0900 (JST) Received: from dcvr.yhbt.net (dcvr.yhbt.net [64.71.152.64]) by neon.ruby-lang.org (Postfix) with ESMTPS id 858DF120755 for ; Thu, 22 Jun 2017 16:44:29 +0900 (JST) Received: from localhost (dcvr.yhbt.net [127.0.0.1]) by dcvr.yhbt.net (Postfix) with ESMTP id 6117F20282; Thu, 22 Jun 2017 07:44:26 +0000 (UTC) Date: Thu, 22 Jun 2017 07:44:26 +0000 From: Eric Wong To: ruby-core@ruby-lang.org Message-ID: <20170622074426.GA19679@dcvr> References: MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-ML-Name: ruby-core X-Mail-Count: 81739 Subject: [ruby-core:81739] Re: [Ruby trunk Feature#9145][Closed] Queue#pop(true) return nil if empty instead of raising ThreadError 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" glass.saga@gmail.com wrote: > Issue #9145 has been updated by Glass_saga (Masaki Matsushita). > > Status changed from Feedback to Closed > > Currently, Queue#pop takes non_block flag. No, I don't think this should be closed. I think Justin's point was: Currently, it is impossible to know if a queue is closed (permanent condition) or if it is empty (temporary condition). So at the very least, a different exception should be raised: Justin Collins wrote: > Alternatively, raise an exception that is a subclass of > ThreadError with a more specific name, such as "QueueEmpty". > This would be a small improvement while remaining compatible > with existing code. On a side note, relying on exceptions for flow control has all the same performance and $DEBUG noise problems it did with IO#*_nonblock [ruby-core:38666] [Feature #5138] But thinking of an efficient API for that is tricky :<