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=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.2 Received: from neon.ruby-lang.org (neon.ruby-lang.org [221.186.184.75]) by dcvr.yhbt.net (Postfix) with ESMTP id 22BE81F453 for ; Wed, 13 Feb 2019 09:45:02 +0000 (UTC) Received: from neon.ruby-lang.org (localhost [IPv6:::1]) by neon.ruby-lang.org (Postfix) with ESMTP id 1812912169C; Wed, 13 Feb 2019 18:44:59 +0900 (JST) Received: from dcvr.yhbt.net (dcvr.yhbt.net [64.71.152.64]) by neon.ruby-lang.org (Postfix) with ESMTPS id 83949121430 for ; Wed, 13 Feb 2019 18:44:53 +0900 (JST) Received: from localhost (dcvr.yhbt.net [127.0.0.1]) by dcvr.yhbt.net (Postfix) with ESMTP id C08661F453; Wed, 13 Feb 2019 09:44:52 +0000 (UTC) Date: Wed, 13 Feb 2019 09:44:52 +0000 From: Eric Wong To: ruby-core@ruby-lang.org Message-ID: <20190213094452.qwgtzs6rbliymyhd@dcvr> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-ML-Name: ruby-core X-Mail-Count: 91528 Subject: [ruby-core:91528] Re: Technical question on ruby Thread::Light scheduling 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" Responding to technical bits from a private email I got regarding this topic: (original asker Bcc-ed). Note: I'm focused on another project nowadays, so I have almost no time or interest in Ruby. Maybe 2020 will be different. Non-technical questions to be answered privately. > You mention in > https://80x24.org/ruby.git/commit/?h=thread-light&id=2d5766886fc6b8575daaa79d4549c944b464eab4 > : > > Thread::Light scheduling happens at a few, well-defined points > + * only when the execution context cannot proceed (e.g. waiting > on > + * a message from a socket, pipe, Queue, or similar). > > - Given the fact that Ruby Threads are rescheduled when they block on IO, > does the above mean you have some fine-grained scheduling mechanism that > switches auto-fibers in-between Thread switching? Yes. Except auto-fibers can only switch when socket/pipe I/O cannot proceed. FS I/O blocking is not easily/portably detectable. > - Regading Mutexes, if you make them 'just' auto-fiber aware then you > should get Thread-awareness for free, right? No. I've already forgotten the exact details (but maybe my old emails/docs describe it); but I seem to recall doing deadlock checking right is difficult. So preventing auto-fiber switching inside a mutex lock seemed to be the most logical way towards predictable/safe behavior (similar to Thread.exclusive in 1.8). > - you mention you need native threads yourself to support FS access with > high-throughput/low latencies. Is this because ruby 'provides' time-slicing > sheduling ? No, not at all. It's because the ONLY way to get any sort of parallelism for most FS syscalls is to use native threads. POSIX AIO only offers functionality of read/write/fsync. Stuff like open/stat/unlink/link/rename/readdir/pread/pwrite requires native threads (or processes) for parallelism. > - In golang they have an integrated netpoller, which I wager is in line > with your idea of a single IO events 'distributor'. It relies on epoll for > linux, kqueu for bsd, iocp for windows etc. > Just mentioning in case you want to look for some inspiration: > https://golang.org/src/runtime/netpoll.go (OS-generic), > https://golang.org/src/runtime/netpoll_epoll.go, > https://golang.org/src/runtime/netpoll_kqueue.go. Maybe... but no mention of EV_ONESHOT or EPOLLONESHOT; so it looks like they'll get extra/unneeded wakeups and netpollready/netpollunblock needs to filter out duplicate events. > - Regarding fiber/coroutine/auto-fiber migration between ruby Threads, > golang has solved the problem in an elegant way: goroutine stack lives in > program heap with malloc, switching goroutines need only to save and > restore 3 registers: Program Counter, Stack Pointer and DX. Ruby seems to > be a bit stuck into "moving stacks between threads" mentality, when the > ligher abstractions should be oblivious to underlying OS threads. This > allows you to schedule the next goroutine/auto-fiber in the runq into > another unblocked thread and run it right away. Care to share some thoughts? Ruby could do this if we dropped support for C-extensions, too. But the current VM itself is like one giant C-extension, and critical parts which benefit from auto-fiber scheduling ("socket"), are, too; as are popular gems which would benefit from this feature, such as "pg" or "mysql2"