From: Eric Wong <normalperson@yhbt.net>
To: ruby-core@ruby-lang.org
Subject: [ruby-core:81500] Re: [Ruby trunk Feature#13618] [PATCH] auto fiber schedule for rb_wait_for_single_fd and rb_waitpid
Date: Thu, 1 Jun 2017 09:18:10 +0000 [thread overview]
Message-ID: <20170601091810.GA13301@starla> (raw)
In-Reply-To: <redmine.journal-65205.20170601021541.9ae6b580c3762316@ruby-lang.org>
ko1@atdot.net wrote:
> Issue #13618 has been updated by ko1 (Koichi Sasada).
>
>
> Thank you for your great work.
You're welcome :)
> # summary of this comment
>
> Recent days I'm thinking about this feature's "safety" or "dependability".
> Because of this issue, I think it is difficult to employ this feature right now.
I disagree. I do not recall Ruby 1.8 Threads being a big problem
for Rubyists. Modern Rubyists seem OK using native Threads
("OK", not "great" :)
We can improve APIs (maybe more Queue/SizedQueue, less Mutex).
What auto-Fiber provides is an option to reduce memory usage and
improve scalability without rewriting existing synchronous
codebases (e.g. Rack + middlewares).
In my experience, I think Ruby gained more users during 1.8-era
when it memory usage was low for green threads; and lost users
as 1.9/2.x memory usage increase (and I guess 3rd-party libs
grew, too).
The safety difference between auto-Fiber and Thread is a minor
point. Lowering memory usage while retaining compatibility with
existing synchronous code is my reason for working on this.
> * It is difficult to know which operations should be run in atomic (users write code without checking atomicity).
> * It is difficult to find out which method can switch.
> * Not only user writing code, but also all library code can switch fibers.
> * This means that we need to check all of library code to know that they don't violate atomic assumptions.
> * It introduced non-deterministic behavior (with `Fiber.yield` it will be deterministic behavior and it is easy to reproduce the problem).
Yes; we will document all switch points in RDoc and NEWS,
of course (maybe write a separate doc/auto-fiber.rdoc)
> This kind of difficulties are same as threading. The impact
> can be smaller than threading (because threading can switch
> anywhere and it is very hard to predict the behavior.
> Auto-fibers switch only at blocking operations especially on
> IO operations).
Right, I think auto-fiber will have some of the same (probably
minor) difficulties as threading. However, I do not believe it
is a big problem since Rubyists should already be used to
threading.
> # Consideration
>
> To solve this behavior, we have several choice.
>
> (1) Introduce synchronization mechanisms for auto-fibers
>
> Like Mutex, Queue and so on.
Yes, I think Queue/SizedQueue should be able to respect Fiber
scheduling boundaries. Queue/SizedQueue are especially useful
and I plan to implement auto-fiber support for that.
I am not sure about Mutex... (can we defer to Matz for decisions?)
> On Ruby 1.8 era, we have `Thread.exclusive` to prohibit thread-switching.
>
> I don't want to choice this option because it is what I want to avoid from Ruby.
Right.
Maybe Mutex#synchronize can prohibit auto-switch (or, it
will show a warning or raise at auto-switch points).
> (2) Introduce limitations
>
> The problem "It is difficult to find out which method can switch" is because we need to check whole of code. If we can restrict the auto-fiber switching, this problem can be smaller.
Right now for IO, it is double opt-in:
It requires _both_ Fiber#start and IO#nonblock=true.
Sidenote:
As a Rubyist who studies the Linux kernel; I consider it
imperative to give Rubyists the choice to make real blocking
syscalls (not the "fake blocking" with auto-fiber/green
threads).
This is because Linux can optimize "wake-one" situations to:
a) give round-robin load distribution across independent processes
b) avoid thundering herd with multiple threads/processes
c) (I forget...)
(sorry I forgot to note this in my original ticket, but it will
be in the final docs)
> (2-1) Introduce Fiber switching methods
>
> Instead of implicit blocking (IO) operations, introduce explicit blocking operations can switch. We can check all of source code by grep.
I am against this. Instead, I want it to be easy to port
existing Thread-aware codebases over.
Notice my example test script used net/http from stdlib.
I would like to use existing stdlib (net/*, webrick, drb, ...)
as much as possible without modifications. That means many
existing Ruby libraries can work transparently.
> (2-2) Check context
>
> Permit fiber switching only at permitted places, by block, pragma, and so on.
>
> ```
> # auto-fiber: true # <- this file can switch fibers automatically
> Fiber.new(auto: true){
> ...
> io.read # can switch
> ...
> something_defined_in_gem # can't switch
> ...
> }
> ```
>
> I think other languages like Python, JavaScript employs this idea. I need to survey more on such languages.
I do not like this, either. I admit I am not familiar with
those languages. I think we should strive to make existing
Thread-aware Ruby code work well, and as transparently as possible...
> (3) Something else cleaver
>
> Introducing debugger is one choice (maybe it is easy than threading issues).
> But we can't avoid troubles (and maybe the troubles should be not frequent, non-reproducible).
Adding Tracepoint to help track auto-switch should be done
(honestly I have never used this feature in ruby :x).
And yes, I think native threading bugs are trickier to track down
than auto-Fiber switching. Just remember, today we have native
threading and things are OK. And I think there were more happy
Rubyists in 1.8 days.
> Other option is to introduce hooks to implement auto-fibers and provide auto-fibers by gems and advanced users know the above risk use this feature. But not good idea because we can't provide good way to write for many people.
>
> thought?
Again, no. I am really in favor of making it easy to port
existing Thread-aware code to auto-Fiber.
Again; from my experience; I do not believe many Ruby
programmers had safety problems with 1.8 green threads.
Today we have Rubyists who are already used to 1.9/2.x native
Thread already.
The safety improvement is a minor point.
next prev parent reply other threads:[~2017-06-01 9:18 UTC|newest]
Thread overview: 173+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <redmine.issue-13618.20170601001407@ruby-lang.org>
2017-06-01 0:14 ` [ruby-core:81492] [Ruby trunk Feature#13618] [PATCH] auto fiber schedule for rb_wait_for_single_fd and rb_waitpid normalperson
2017-06-01 0:36 ` [ruby-core:81493] " Eric Wong
2017-06-29 6:11 ` [ruby-core:81826] " Eric Wong
2018-08-27 20:27 ` [ruby-core:88695] " Eric Wong
2018-09-01 13:13 ` [ruby-core:88800] " Eric Wong
2018-09-02 9:24 ` [ruby-core:88806] " Eric Wong
2018-09-12 20:27 ` [ruby-core:88961] " Eric Wong
2018-11-14 22:03 ` [ruby-core:89799] Thread::Light#raise and Thread::Light#kill Eric Wong
2018-11-20 8:44 ` [ruby-core:89900] Thread::Light patch against r65832 Eric Wong
2018-11-20 10:20 ` [ruby-core:89904] " Koichi Sasada
2018-11-20 15:15 ` [ruby-core:89909] " Eric Wong
2018-11-21 10:59 ` [ruby-core:89920] " Eric Wong
2018-12-15 12:19 ` [ruby-core:90546] Re: [Ruby trunk Feature#13618] [PATCH] auto fiber schedule for rb_wait_for_single_fd and rb_waitpid Eric Wong
2017-06-01 2:15 ` [ruby-core:81495] " ko1
2017-06-01 9:18 ` Eric Wong [this message]
2017-06-01 5:48 ` [ruby-core:81498] " ko1
2017-06-01 14:40 ` [ruby-core:81507] " ko1
2017-06-01 21:51 ` [ruby-core:81514] " Eric Wong
2017-06-02 18:05 ` [ruby-core:81537] " eregontp
2017-06-02 23:18 ` [ruby-core:81543] " Eric Wong
2017-06-09 8:15 ` [ruby-core:81631] " samuel
2017-06-09 20:32 ` [ruby-core:81643] " Eric Wong
2017-06-14 2:13 ` [ruby-core:81672] " samuel
2017-06-14 2:49 ` [ruby-core:81674] " Eric Wong
2017-06-15 1:56 ` [ruby-core:81687] " samuel
2017-06-15 20:28 ` [ruby-core:81695] " Eric Wong
2017-06-19 13:17 ` [ruby-core:81721] " samuel
2017-06-20 19:08 ` [ruby-core:81732] " Eric Wong
2017-07-13 8:37 ` [ruby-core:82028] " ko1
2017-07-13 22:31 ` [ruby-core:82040] " Eric Wong
2017-07-31 9:19 ` [ruby-core:82214] " samuel
2017-07-31 9:21 ` [ruby-core:82215] " samuel
2017-08-30 3:16 ` [ruby-core:82518] " mame
2017-08-31 5:58 ` [ruby-core:82552] " Eric Wong
2017-09-12 5:40 ` [ruby-core:82756] " Eric Wrong
2017-09-28 1:06 ` [ruby-core:83034] " Eric Wrong
2017-12-07 4:30 ` [ruby-core:84118] " Eric Wong
2017-12-10 22:30 ` [ruby-core:84149] " samuel
2017-12-11 1:37 ` [ruby-core:84153] " Eric Wong
2018-01-23 11:35 ` [ruby-core:84980] [Ruby trunk Feature#13618][Assigned] " hsbt
2018-01-23 17:31 ` [ruby-core:85012] " Eric Wong
2018-01-24 21:51 ` [ruby-core:85081] " Eric Wong
2018-01-24 22:01 ` [ruby-core:85082] " Eric Wong
2018-01-25 1:13 ` [ruby-core:85087] " Daniel Ferreira
2018-01-28 14:09 ` [ruby-core:85181] " Koichi Sasada
2018-01-28 20:00 ` [ruby-core:85189] " Eric Wong
2018-01-28 14:01 ` [ruby-core:85180] " Koichi Sasada
2018-01-28 11:02 ` [ruby-core:85173] " Eric Wong
2018-01-28 14:32 ` [ruby-core:85183] " Koichi Sasada
2018-01-25 1:15 ` [ruby-core:85088] [Ruby trunk Feature#13618] " danieldasilvaferreira
2018-01-25 4:34 ` [ruby-core:85094] " Eric Wong
2018-01-25 5:06 ` [ruby-core:85095] " Daniel Ferreira
2018-01-26 10:16 ` [ruby-core:85128] " samuel
2018-01-26 19:13 ` [ruby-core:85136] " Eric Wong
2018-01-26 20:31 ` [ruby-core:85138] " Daniel Ferreira
2018-01-26 21:36 ` [ruby-core:85139] " Eric Wong
2018-01-27 1:08 ` [ruby-core:85140] " hsbt
2018-01-27 1:17 ` [ruby-core:85141] " danieldasilvaferreira
2018-01-27 3:45 ` [ruby-core:85144] " danieldasilvaferreira
2018-01-28 10:47 ` [ruby-core:85171] " Eric Wong
2018-01-27 23:34 ` [ruby-core:85162] " merch-redmine
2018-01-28 0:02 ` [ruby-core:85163] " danieldasilvaferreira
2018-01-28 0:33 ` [ruby-core:85164] " danieldasilvaferreira
2018-01-28 10:54 ` [ruby-core:85172] " Eric Wong
2018-01-28 5:20 ` [ruby-core:85168] " sam.saffron
2018-01-28 10:41 ` [ruby-core:85170] " Eric Wong
2018-01-28 12:29 ` [ruby-core:85174] " danieldasilvaferreira
2018-01-28 17:50 ` [ruby-core:85186] " danieldasilvaferreira
2018-01-28 20:18 ` [ruby-core:85190] " Eric Wong
2018-01-28 20:43 ` [ruby-core:85191] " danieldasilvaferreira
2018-01-28 21:19 ` [ruby-core:85193] " Eric Wong
2018-01-29 0:39 ` [ruby-core:85199] " sam.saffron
2018-01-29 4:42 ` [ruby-core:85204] " Eric Wong
2018-01-29 5:06 ` [ruby-core:85206] " sam.saffron
2018-01-29 5:14 ` [ruby-core:85207] " Koichi Sasada
2018-01-29 9:48 ` [ruby-core:85217] " Eric Wong
2018-01-29 5:38 ` [ruby-core:85209] " sam.saffron
2018-01-29 20:56 ` [ruby-core:85235] " shannonskipper
2018-01-29 21:28 ` [ruby-core:85236] " sam.saffron
2018-01-29 22:23 ` [ruby-core:85237] " Eric Wong
2018-01-31 2:48 ` [ruby-core:85273] " samuel
2018-02-02 5:46 ` [ruby-core:85335] " sam.saffron
2018-02-02 6:22 ` [ruby-core:85336] " Eric Wong
2018-02-03 1:36 ` [ruby-core:85353] " sam.saffron
2018-02-03 9:33 ` [ruby-core:85362] " Eric Wong
2018-02-04 6:14 ` [ruby-core:85371] " jjyruby
2018-02-05 21:42 ` [ruby-core:85417] " Eric Wong
2018-02-08 0:25 ` [ruby-core:85472] " sam.saffron
2018-02-13 22:39 ` [ruby-core:85531] " Eric Wong
2018-02-15 3:22 ` [ruby-core:85575] " samuel
2018-02-15 4:02 ` [ruby-core:85576] " Eric Wong
2018-02-15 13:13 ` [ruby-core:85585] " samuel
2018-02-20 6:42 ` [ruby-core:85674] " matz
2018-02-20 9:06 ` [ruby-core:85686] " Eric Wong
2018-02-21 1:52 ` [ruby-core:85704] " Koichi Sasada
2018-02-21 8:07 ` [ruby-core:85726] " Eric Wong
2018-02-21 8:23 ` [ruby-core:85727] " Koichi Sasada
2018-02-21 14:55 ` [ruby-core:85732] " jjyruby
2018-02-28 19:25 ` [ruby-core:85868] " keystonelemur
2018-03-13 2:57 ` [ruby-core:86092] " samuel
2018-04-21 11:23 ` [ruby-core:86639] " Eric Wong
2018-04-26 4:57 ` [ruby-core:86689] " samuel
2018-04-26 6:01 ` [ruby-core:86691] " Eric Wong
2018-04-30 1:24 ` [ruby-core:86768] " samuel
2018-04-30 10:25 ` [ruby-core:86774] " Eric Wong
2018-04-30 1:37 ` [ruby-core:86769] " samuel
2018-04-30 10:47 ` [ruby-core:86775] " Eric Wong
2018-05-02 5:20 ` [ruby-core:86821] " samuel
2018-05-02 7:54 ` [ruby-core:86826] " Eric Wong
2018-05-02 8:38 ` [ruby-core:86829] " samuel
2018-05-02 10:56 ` [ruby-core:86832] " Eric Wong
2018-05-02 23:36 ` [ruby-core:86850] " samuel
2018-05-03 1:15 ` [ruby-core:86853] " Eric Wong
2018-05-05 13:06 ` [ruby-core:86910] " samuel
2018-05-06 3:03 ` [ruby-core:86915] " Eric Wong
2018-05-07 11:39 ` [ruby-core:86929] " samuel
2018-05-10 20:06 ` [ruby-core:86972] " Eric Wong
2018-05-08 5:25 ` [ruby-core:86942] " samuel
2018-05-08 6:40 ` [ruby-core:86943] " samuel
2018-05-08 7:01 ` [ruby-core:86944] " samuel
2018-05-10 21:09 ` [ruby-core:86973] " Eric Wong
2018-05-11 2:09 ` [ruby-core:86976] " samuel
2018-06-13 1:16 ` [ruby-core:87484] " Eric Wong
2018-06-18 0:59 ` [ruby-core:87504] " Eric Wong
2018-07-04 7:37 ` [ruby-core:87776] " funny.falcon
2018-07-04 8:45 ` [ruby-core:87779] " samuel
2018-07-04 16:40 ` [ruby-core:87786] " funny.falcon
2018-07-05 7:20 ` [ruby-core:87803] " funny.falcon
2018-07-05 8:43 ` [ruby-core:87810] " funny.falcon
2018-07-05 9:35 ` [ruby-core:87811] " samuel
2018-07-05 18:12 ` [ruby-core:87818] " funny.falcon
2018-07-05 21:55 ` [ruby-core:87822] " samuel
2018-07-06 7:48 ` [ruby-core:87835] " funny.falcon
2018-07-06 9:16 ` [ruby-core:87837] " samuel
2018-07-06 18:10 ` [ruby-core:87839] " funny.falcon
2018-07-06 21:11 ` [ruby-core:87840] " Eric Wong
2018-08-08 1:21 ` [ruby-core:88331] " samuel
2018-08-08 8:48 ` [ruby-core:88350] " Eric Wong
2018-08-08 11:14 ` [ruby-core:88352] " Matthew Kerwin
2018-08-09 8:04 ` [ruby-core:88374] " samuel
2018-08-09 8:25 ` [ruby-core:88376] " samuel
2018-08-09 8:34 ` [ruby-core:88378] " Eric Wong
2018-08-10 9:33 ` [ruby-core:88433] " ko1
2018-08-14 0:42 ` [ruby-core:88467] " Eric Wong
2018-08-14 8:22 ` [ruby-core:88476] " Koichi Sasada
2018-08-14 17:47 ` [ruby-core:88484] " Eric Wong
2018-08-10 11:45 ` [ruby-core:88437] " samuel
2018-08-14 9:00 ` [ruby-core:88478] " danieldasilvaferreira
2018-08-14 18:25 ` [ruby-core:88486] " Eric Wong
2018-09-04 21:36 ` [ruby-core:88838] " Greg.mpls
2018-09-05 21:47 ` [ruby-core:88873] " Eric Wong
2018-09-13 8:17 ` [ruby-core:88989] " matz
2018-09-13 9:18 ` [ruby-core:88992] " Eric Wong
2018-09-13 16:23 ` [ruby-core:88999] " shevegen
2018-09-21 17:58 ` [ruby-core:89120] " shannonskipper
2018-09-28 2:35 ` [ruby-core:89204] " Eric Wong
2018-11-20 20:58 ` [ruby-core:89913] " shevegen
2018-11-22 1:28 ` [ruby-core:89939] " me
2018-11-22 2:14 ` [ruby-core:89943] " Eric Wong
2018-11-22 10:40 ` [ruby-core:89968] Thread::Light updated for r65925 (sleep fix) Eric Wong
2018-11-28 11:05 ` [ruby-core:90115] Thread::Light r66072 Eric Wong
2018-11-22 15:40 ` [ruby-core:89978] [Ruby trunk Feature#13618] [PATCH] auto fiber schedule for rb_wait_for_single_fd and rb_waitpid me
2018-11-28 10:22 ` [ruby-core:90111] " matz
2018-11-28 10:44 ` [ruby-core:90112] " Eric Wong
2018-11-28 12:19 ` [ruby-core:90117] " takashikkbn
2018-11-28 19:51 ` [ruby-core:90134] " Eric Wong
2018-11-28 20:07 ` [ruby-core:90136] " samuel
2018-11-29 0:16 ` [ruby-core:90141] " Eric Wong
2018-11-29 11:26 ` [ruby-core:90161] Thread::Light#run and Thread::Light#wakeup Eric Wong
2019-01-01 22:58 ` [ruby-core:90846] [Ruby trunk Feature#13618] [PATCH] auto fiber schedule for rb_wait_for_single_fd and rb_waitpid me
2019-01-04 14:49 ` [ruby-core:90890] " Eric Wong
2019-02-13 9:44 ` [ruby-core:91528] Re: Technical question on ruby Thread::Light scheduling Eric Wong
2019-05-07 7:24 ` [ruby-core:92579] [Ruby trunk Feature#13618] [PATCH] auto fiber schedule for rb_wait_for_single_fd and rb_waitpid shevegen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-list from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.ruby-lang.org/en/community/mailing-lists/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20170601091810.GA13301@starla \
--to=ruby-core@ruby-lang.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).