From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS4713 221.184.0.0/13 X-Spam-Status: No, score=-3.8 required=3.0 tests=AWL,BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.1 Received: from neon.ruby-lang.org (neon.ruby-lang.org [221.186.184.75]) by dcvr.yhbt.net (Postfix) with ESMTP id 075FC1F403 for ; Mon, 18 Jun 2018 00:59:50 +0000 (UTC) Received: from neon.ruby-lang.org (localhost [IPv6:::1]) by neon.ruby-lang.org (Postfix) with ESMTP id D10B5120953; Mon, 18 Jun 2018 09:59:47 +0900 (JST) Received: from dcvr.yhbt.net (dcvr.yhbt.net [64.71.152.64]) by neon.ruby-lang.org (Postfix) with ESMTPS id 39E6F120945 for ; Mon, 18 Jun 2018 09:59:43 +0900 (JST) Received: from localhost (dcvr.yhbt.net [127.0.0.1]) by dcvr.yhbt.net (Postfix) with ESMTP id 2FF0D1F403; Mon, 18 Jun 2018 00:59:40 +0000 (UTC) Date: Mon, 18 Jun 2018 00:59:40 +0000 From: Eric Wong To: ruby-core@ruby-lang.org Message-ID: <20180618005940.6qsfngjjucgcknpg@dcvr> References: <20180613011633.4zbqrakpaic6seps@dcvr> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20180613011633.4zbqrakpaic6seps@dcvr> X-ML-Name: ruby-core X-Mail-Count: 87504 Subject: [ruby-core:87504] Re: [Ruby trunk Feature#13618] [PATCH] auto fiber schedule for rb_wait_for_single_fd and rb_waitpid 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" Also, I will extract timeout support into separate feature. The basic idea is that (regardless of how efficient(*) Timeout is): Timeout.timeout { io.read(...) } Timeout.timeout { io.write(...) } Timeout.timeout { io.read(...) } Timeout.timeout { io.write(...) } ... Will always be less efficient than: Timeout.timeout do io.read(...) io.write(...) io.read(...) io.write(...) ... end So we should encourage the latter, not the former (as this patch does). I will try to make both as fast as possible, but the former will always be faster because registering the timeout (either in userspace in our VM or the OS kernel) always has a highish cost.