From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS4713 221.184.0.0/13 X-Spam-Status: No, score=-4.1 required=3.0 tests=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.2 Received: from neon.ruby-lang.org (neon.ruby-lang.org [221.186.184.75]) by dcvr.yhbt.net (Postfix) with ESMTP id EB1C41F609 for ; Thu, 29 Nov 2018 00:16:14 +0000 (UTC) Received: from neon.ruby-lang.org (localhost [IPv6:::1]) by neon.ruby-lang.org (Postfix) with ESMTP id 1168C121461; Thu, 29 Nov 2018 09:16:13 +0900 (JST) Received: from dcvr.yhbt.net (dcvr.yhbt.net [64.71.152.64]) by neon.ruby-lang.org (Postfix) with ESMTPS id B154012138F for ; Thu, 29 Nov 2018 09:16:09 +0900 (JST) Received: from localhost (dcvr.yhbt.net [127.0.0.1]) by dcvr.yhbt.net (Postfix) with ESMTP id 2BEEC1F609; Thu, 29 Nov 2018 00:16:07 +0000 (UTC) Date: Thu, 29 Nov 2018 00:16:06 +0000 From: Eric Wong To: ruby-core@ruby-lang.org Message-ID: <20181129001606.dkrnkr7ea6bvjiui@dcvr> References: MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-ML-Name: ruby-core X-Mail-Count: 90141 Subject: [ruby-core:90141] 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" samuel@oriontransfer.net wrote: > @k0kubun I like the general ideas presented here but the > implementation is too heavy/specific for my use case. For > example, it won't work on JRuby, TruffleRuby, or other > implementations. That's the major benefit of using a gem for > the reactor implementation. Fiber doesn't really benefit (in terms of memory use) on JRuby, either, right? I don't know much about implementations outside of this one. > Additionally, I need to use Fiber for task switching. Does > `Thread::Light` allow `yield`/`resume`? We can expose yield/resume easily; but I don't know if there is use case for it... There is already Kernel#sleep support and Thread::Light#run Maybe a Thread::Light#raise implementation? I don't know if interrupts should be handled via rb_thread_t or rb_execution_context_t (right now, it's mixed and confusing) > The tricky part about supporting a different backend is > whether it changes semantics of operations. If it does, it's a > big problem. What semantic changes are you talking about? I'm doing my best to make things transparent to native Thread users. The biggest difference is waitpid probably won't benefit on Windows because lack of SIGCHLD (maybe @usa can workaround it with polling or IOCP). > If you try to use two different libraries of code > that expect different backend semantics, it can cause many > headache. That's why I think as an IO reactor, this is really > great, but as a high level interface, I'm not convinced I can > use it. Really, stop thinking in terms of "reactor". It does not map well to applications requiring many native threads (as I've said this many times, already). There is no reactor for this and never will be. Instead, the scheduling mechanism wires into kernel-provided queues (e.g. "kqueue", I've said this before, too).