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.6 required=3.0 tests=BAYES_00,DKIM_ADSP_CUSTOM_MED, FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM,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 29F201F62D for ; Thu, 5 Jul 2018 18:12:26 +0000 (UTC) Received: from neon.ruby-lang.org (localhost [IPv6:::1]) by neon.ruby-lang.org (Postfix) with ESMTP id 17233120C71; Fri, 6 Jul 2018 03:12:23 +0900 (JST) Received: from o1678916x28.outbound-mail.sendgrid.net (o1678916x28.outbound-mail.sendgrid.net [167.89.16.28]) by neon.ruby-lang.org (Postfix) with ESMTPS id 6AD62120C68 for ; Fri, 6 Jul 2018 03:12:20 +0900 (JST) Received: by filter0082p3mdw1.sendgrid.net with SMTP id filter0082p3mdw1-5892-5B3E5F81-8 2018-07-05 18:12:17.223965789 +0000 UTC Received: from herokuapp.com (ec2-184-73-60-204.compute-1.amazonaws.com [184.73.60.204]) by ismtpd0048p1mdw1.sendgrid.net (SG) with ESMTP id k_QGsuHqTcqu4Ant74Qo1w Thu, 05 Jul 2018 18:12:17.173 +0000 (UTC) Date: Thu, 05 Jul 2018 18:12:17 +0000 (UTC) From: funny.falcon@gmail.com To: ruby-core@ruby-lang.org Message-ID: References: Mime-Version: 1.0 X-Redmine-MailingListIntegration-Message-Ids: 63205 X-Redmine-Project: ruby-trunk X-Redmine-Issue-Id: 13618 X-Redmine-Issue-Author: normalperson X-Redmine-Issue-Assignee: normalperson X-Redmine-Sender: funny_falcon X-Mailer: Redmine X-Redmine-Host: bugs.ruby-lang.org X-Redmine-Site: Ruby Issue Tracking System X-Auto-Response-Suppress: All Auto-Submitted: auto-generated X-SG-EID: ync6xU2WACa70kv/Ymy4QrNMhiuLXJG8OTL2vJD1yS5M7365j1YY0irv/G1fD+9PAGgR+1KnJ7eBPd lLaSmkpGhJ1glbroP54zaIpLr7kW8dXs5LJSYTVNJLNrGW9KHRqBkX6Xgl1XmhJEHYtUEUWDNt/yHh HRE9bj20K8YpVGk0iTaSt+Knvzx5oVPMnA5FmLnPIHY1e4+miLWGL45gAw== X-ML-Name: ruby-core X-Mail-Count: 87818 Subject: [ruby-core:87818] [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" Issue #13618 has been updated by funny_falcon (Yura Sokolov). > It's also going to be more useful for existing code bases like ActionCable, Puma, Async, etc which use their own IO scheduler. They have their own IO scheduler because ruby had just native threads, which are bad as IO scheduler. Ok, I'm not totally right: no scheduler will be good enough for everyone. But I believe, single green scheduler will be good enough for most of things. > There is no way you can not be compatible with Thread.scheduler if you use standard Ruby IO. Can you give me an example where this isn't true? No, looks like I'm not confident to answer :-( Edit: after writing rest of this, I've recognized, that standard Ruby Mutex and Queue will not be compatible with Thread.scheduler. > Yes, but you pay all the overhead of "it might be a thread", and gain none of the benefits of green threads. It has benefits both performance and uniformity benefits. It will be fast, because scheduler still can switch "threads" sitting on a same native thread as fast as Fibers. Uniformity, because there will be just single set of tools for synchronization: Mutex, ConditionVariable, Queue. All these tools are needed regardless of "native" vs "green" scheduler. If these utils will be universal, they will be easily composed together. Otherwise mix of "native"/"green" threading will become nightmare. How they will be composed with `Thread.scheduler`? > Programmer sanity is much more important to me than performance. That is my stand point too. I believe, less things programmer need to teach, is better. So there should be: - use Threads, Mutex, Queue. If you want performance of eventloop, pass `scheduler` parameter to Thread.create. That is all. With `Thread.scheduler=` it becomes: - you may use Threads, Mutex, Queue. - but if you want performance of eventloop, you need to choose library, that provides scheduler, Mutex, Queue, use that library's primitives thorough your code, and never mix core Mutex with that library's Mutex, if you occasionally need to use native threads. Seriously: Ruby will never be that low level language that will gain serious performance through careful separation of "green" vs "native" thread concepts. Look at Go (yeah, i've said that, sorry): it were built to be fast practical language. It has "green threads". But it has no separation "green vs native". Single option, that digs into that separation, is "runtime.LockThread()" to give the goroutine separate scheduler on separate native thread. And Go have no non-blocking io visible to user :-O . It is pretty annoying. Sure, if one want to gain 99.99% of hardware performance, one will not use Go. She will use C/C++/Rust, will build their own scheduler and event loop. But if 95% is just ok, than Go is right tool. Doubtfully there will be so huge performance difference between "explicit Thread.scheduler= + that's scheduler synchronization primitives" vs "standard hybrid Thread with standard hybrid Mutex/Queue". Sure, hybrid Threads will be much harder to accomplish. Sure, I could be mistaken entirely. ---------------------------------------- Feature #13618: [PATCH] auto fiber schedule for rb_wait_for_single_fd and rb_waitpid https://bugs.ruby-lang.org/issues/13618#change-72836 * Author: normalperson (Eric Wong) * Status: Assigned * Priority: Normal * Assignee: normalperson (Eric Wong) * Target version: ---------------------------------------- ``` auto fiber schedule for rb_wait_for_single_fd and rb_waitpid Implement automatic Fiber yield and resume when running rb_wait_for_single_fd and rb_waitpid. The Ruby API changes for Fiber are named after existing Thread methods. main Ruby API: Fiber#start -> enable auto-scheduling and run Fiber until it automatically yields (due to EAGAIN/EWOULDBLOCK) The following behave like their Thread counterparts: Fiber.start - Fiber.new + Fiber#start (prelude.rb) Fiber#join - run internal scheduler until Fiber is terminated Fiber#value - ditto Fiber#run - like Fiber#start (prelude.rb) Right now, it takes over rb_wait_for_single_fd() and rb_waitpid() function if the running Fiber is auto-enabled (cont.c::rb_fiber_auto_sched_p) Changes to existing functions are minimal. New files (all new structs and relations should be documented): iom.h - internal API for the rest of RubyVM (incomplete?) iom_internal.h - internal header for iom_(select|epoll|kqueue).h iom_epoll.h - epoll-specific pieces iom_kqueue.h - kqueue-specific pieces iom_select.h - select-specific pieces iom_pingable_common.h - common code for iom_(epoll|kqueue).h iom_common.h - common footer for iom_(select|epoll|kqueue).h Changes to existing data structures: rb_thread_t.afrunq - list of fibers to auto-resume rb_vm_t.iom - Ruby I/O Manager (rb_iom_t) :) Besides rb_iom_t, all the new structs are stack-only and relies extensively on ccan/list for branch-less, O(1) insert/delete. As usual, understanding the data structures first should help you understand the code. Right now, I reuse some static functions in thread.c, so thread.c includes iom_(select|epoll|kqueue).h TODO: Hijack other blocking functions (IO.select, ...) I am using "double" for timeout since it is more convenient for arithmetic like parts of thread.c. Most platforms have good FP, I think. Also, all "blocking" functions (rb_iom_wait*) will have timeout support. ./configure gains a new --with-iom=(select|epoll|kqueue) switch libkqueue: libkqueue support is incomplete; corner cases are not handled well: 1) multiple fibers waiting on the same FD 2) waiting for both read and write events on the same FD Bugfixes to libkqueue may be necessary to support all corner cases. Supporting these corner cases for native kqueue was challenging, even. See comments on iom_kqueue.h and iom_epoll.h for nuances. Limitations Test script I used to download a file from my server: ----8<--- require 'net/http' require 'uri' require 'digest/sha1' require 'fiber' url = 'http://80x24.org/git-i-forgot-to-pack/objects/pack/pack-97b25a76c03b489d4cbbd85b12d0e1ad28717e55.idx' uri = URI(url) use_ssl = "https" == uri.scheme fibs = 10.times.map do Fiber.start do cur = Fiber.current.object_id # XXX getaddrinfo() and connect() are blocking # XXX resolv/replace + connect_nonblock Net::HTTP.start(uri.host, uri.port, use_ssl: use_ssl) do |http| req = Net::HTTP::Get.new(uri) http.request(req) do |res| dig = Digest::SHA1.new res.read_body do |buf| dig.update(buf) #warn "#{cur} #{buf.bytesize}\n" end warn "#{cur} #{dig.hexdigest}\n" end end warn "done\n" :done end end warn "joining #{Time.now}\n" fibs[-1].join(4) warn "joined #{Time.now}\n" all = fibs.dup warn "1 joined, wait for the rest\n" until fibs.empty? fibs.each(&:join) fibs.keep_if(&:alive?) warn fibs.inspect end p all.map(&:value) Fiber.new do puts 'HI' end.run.join ``` ---Files-------------------------------- 0001-auto-fiber-schedule-for-rb_wait_for_single_fd-and-rb.patch (82.8 KB) -- https://bugs.ruby-lang.org/