2020年末にFiberSchdulerについて最初に調べた際に読んだ際のメモが出てきたのでpublishしておく。
http://www.wjwh.eu/posts/2020-12-28-ruby-fiber-scheduler-c-extension.html
このページが一番まとまってるイメージ。
The scheduler is responsible for maintaining a inventory of blocked fibers and resume-ing those fibers when the reason why they were blocked disappears.
Choosing between these possible mechanisms and managing the conversion between Ruby objects and what the OS demands is the task of the scheduler.
Since fibers are thread-local and cannot move between threads, so is the scheduler.
To make the integration seamless for Ruby developers, in Ruby 3.0 and onwards all relevant standard library methods have been patched to yield to the scheduler whenever they encounter a situation where they will block the current fiber.
なるほど賢い。例は Kernel.sleep, IO#wait_readable, IO#wait_writable, IO#read, IO#write and other related methods (e.g. IO#puts, IO#gets), Thread#join, ConditionVariable#wait, Queue#pop, SizedQueue#push とか。
The real power of this becomes apparent when you realize that this means any method in any gem that eventually calls IO#read or IO#write can make use of the scheduler, whether that gem has been written with the scheduler in mind or not.
This immediately makes many gems like database drivers and network libraries scheduler-aware, as long as they don’t use C extensions too heavily. Even if they do, not all is lost. We’ll look at integrating C extensions with the scheduler later.
many useful Ruby gems use C extensions to drop the GVL, perform operations “underneath” the Ruby garbage collector or just for plain speed of execution of computationally expensive operations.
へー
Fiberの欠点①
For one, fibers are thread-local and cannot be moved between threads (yet). (For the purposes of this paragraph, you can also read “Ractor” wherever I wrote “thread”.) This means that any system that wants to scale beyond a single thread will have to run multiple threads, each with their own scheduler.
ちなみにgoだと、 Languages like Haskell and Go solve this issue by “work stealing”, where threads without any work to do can “steal” work from the run queues of other schedulers.
Fiberの欠点②
Another drawback (for POSIX systems only) is that “non-blocking” I/O can actually still block sometimes!
これからできることは以下。
In this first iterations there are still several properties of the system that could be improved upon, such as “work stealing” of fibers between threads and/or Ractors, the addition of a default scheduler, and expansion of the available asynchronous operations.
https://rubyreferences.github.io/rubychanges/3.0.html#non-blocking-fiber-and-scheduler
Notes: The feature is somewhat unprecedented for Ruby in the fact that no default Scheduler implementation is provided. Implementing the Scheduler in a reliable way (probably using some additional non-blocking event loop library) is completely up to the user. Considering that the feature is implemented by Samuel Williams of the Async fame, the Async gem utilizes the new feature since the day of 3.0 release.
とのことなので、gem 'async'のAsync::Schedulerをしようした。
https://github.com/ruby/ruby/blob/master/doc/ractor.md
ractorに関して。
Each Ractor has 1 or more Threads.
Threads in a Ractor shares a Ractor-wide global lock like GIL (GVL in MRI terminology), so they can't run in parallel (without releasing GVL explicitly in C-level). Threads in different ractors run in parallel.
The overhead of creating a Ractor is similar to overhead of one Thread creation.
Ractors communicate with each other and synchronize the execution by message exchanging between Ractors. There are two message exchange protocols: push type (message passing) and pull type.
pushはblockingしない。pushの方が多く使われるらしい。
Copy & Move semantics to send messages
To send unshareable objects as messages, objects are copied or moved.
Copy: use deep-copy.
Move: move membership.
Sender can not access the moved object after moving the object.
Guarantee that at least only 1 Ractor can access the object.
こんなrustみたいなことするのか、草。