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.0 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 D6B331F404 for ; Fri, 26 Jan 2018 19:14:12 +0000 (UTC) Received: from neon.ruby-lang.org (localhost [IPv6:::1]) by neon.ruby-lang.org (Postfix) with ESMTP id E13E9120A85; Sat, 27 Jan 2018 04:14:06 +0900 (JST) Received: from dcvr.yhbt.net (dcvr.yhbt.net [64.71.152.64]) by neon.ruby-lang.org (Postfix) with ESMTPS id 149A3120A7F for ; Sat, 27 Jan 2018 04:13:46 +0900 (JST) Received: from localhost (dcvr.yhbt.net [127.0.0.1]) by dcvr.yhbt.net (Postfix) with ESMTP id 3C51C1F404; Fri, 26 Jan 2018 19:13:44 +0000 (UTC) Date: Fri, 26 Jan 2018 19:13:43 +0000 From: Eric Wong To: ruby-core@ruby-lang.org Message-ID: <20180126191343.GA4142@starla> References: MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-ML-Name: ruby-core X-Mail-Count: 85136 Subject: [ruby-core:85136] 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.org wrote: > In async, I called it `Async::Task`. I think task is a good > name for this kind of thing. In your case, you might want to > consider `Thread::Task`. Since, the lexicographic nesting is > similar to the logical nesting. I prefer shorter names; and I'm not sure if Thread::Task makes sense since it's an alternative to Thread (in some situations); not a helper to Thread (unlike Mutex/Queue/etc). > Regarding kqueue bugs. macOS kqueue implementation is > horrendous. So, `nio4r` doesn't use it AFAIK. Yes, there's also a select() implementation which should be a safe fallback for everybody (not scalable, of course). I'm not sure if OpenBSD/NetBSD/Dragonfly have acceptable kqueue implementations, nowadays, either (FreeBSD seems fine). I will add notes to guide porters into disabling kqueue support, either broadly or fine-grained (per-type), or better, eventually fixing their native kqueue implementations. I also intend to try aio-poll support in future Linux versions (currently under development). > Do you have explicit reactor, or is it implicit per-thread or > per-process? Implicit per-process, and lazily created. kqueue and epoll persistent data structures in the kernel are completely safe to use across multiple threads. select needs no persistent structure in the kernel. Userspace structures are of course done in a thread-safe way and will be adjusted for guilds or GVL removal. If guilds end up being what I expect them to be (implemented via native threads), reactor will likely remain per-process since FDs are still per-process. Some structures and locking will be adjusted for guilds, of course.