Thread Scheduler for light weight concurrency.

[ioquatix]

Ruby concurrency can be greatly enhanced by concurrent, deterministic IO.

Fibers have been shown many times to be a great abstraction for this purpose. They retain normal code flow and don't require any kind of Thread synchronisation. They are enjoyable to write code with because you don't have to concern yourself with thread synchronisation or other complicated issues.

The basic idea is that if some operation would block, it yields the Fiber, and other Fibers within the thread can continue to execute.

There are a number of ways to implement this. Here is a proof of concept to amend the existing rb_io_wait_readable/rb_io_wait_writable.

This design minimally affects the Ruby implementation and allows flexibility for selector implementation. With a small amount of work, we can support EventMachine (65 million downloads), NIO4r (21 million downloads). It would be trivial to back port.

This PR isn't complete but I am seeking feedback. If it's a good idea, I will do my best to see it through to completion, including support for EventMachine and NIO4r.

https://bugs.ruby-lang.org/issues/14736

[ioquatix]

Okay I will resume work on this issue.

[ioquatix]

@hkdnet I fixed that issue. Thanks :)

[ioquatix]

@funny-falcon here is updated example using transfer rather than yield/resume.

As you can see it require no change to underlying C since the scheduler is implemented in pure Ruby.

[ioquatix]

I have rebased on trunk so that tests will run.

[senid231]

What's the status of this feature? Will it be merged?

[ioquatix]

I would like to think we can merge this sooner rather than later. It's minimal surface area and the potential benefit is huge.

That being said, I think that the action of merging this, gently tugs on the rudder controlling the direction of Ruby, and that part might require the input of the captain. So, it's not really my place to merge it, but requires further discussion with Matz et al.

[ioquatix]

@headius @eregon what do you think of the feasibility of implementing this in JRuby/TruffleRuby?

[eregon]

@ioquatix This looks very simple and not invasive for the implementation, so that's definitely a very nice aspect of it.

I'm not super familiar with selectors, but is having hooks in rb_io_wait_readable/rb_io_wait_writable enough? For instance, IO#read will use the read(2) syscall and that blocks by default if the fd is not set as nonblock (which is the default in Ruby AFAIK). Or is the idea the library using these selectors sets every IO it cares about in nonblock mode using e.g., io/nonblock?

[ioquatix]

@eregon yes it's correct, users need to explicitly opt into io.nonblock = true for it to invoke rb_io_wait_*, which I think is acceptable.

[eregon]

@ioquatix What about things like File.read(path) where the fd is not even passed to the Ruby side? This would block, and wouldn't that block the "event loop" making it unresponsive?

[ioquatix]

File.read cannot be made non-blocking as the underling OS normally doesn't support it, so while that's a good point, it's largely irrelevant right now.

A better solution would be to make all IO non-blocking in the context of a Thread with a selector defined, but I think I just wanted to keep this POC simple.

[ioquatix]

Keep in mind, with liburing, apparently some file operations on Linux will become non-blocking, which is interesting.

https://lwn.net/Articles/776428/

[hakusaro]

So, it's not really my place to merge it, but requires further discussion with Matz et al.

Are you going to RubyKaigi? That could be a good venue to engage Matz in.

I think this addition would jive quite well with Ruby 3x3. There are a lot of us glued to MRI. Working with MRI changes is much easier than switching to JRuby for quite a number of people.

[ioquatix]

Yes, I am going to RubyKaigi to discuss it with Matz.

The design goal of this PR is to be simple enough that the majority of Ruby platforms can support it.

[hakusaro]

@ioquatix how'd it go?

[ioquatix]

I got buy in from JRuby and TruffleRuby so we are going to push forward on those fronts to start with, to prove the concept.

[headius]

I got buy in from JRuby

I don't know if I'd say that 😁

Without a design document that we can iterate on I will not commit to anything. We need to see and discuss the design before moving forward.

[ioquatix]

@MSP-Greg do you have any idea why https://github.com/ruby/ruby/pull/1870/checks?check_run_id=584638152#step:14:887 is failing?

[ioquatix]

We discussed it years ago and you said you were keen to try it out :)

[ioquatix]

Sorry, stuffed up the PR, here is the link: #3032

[MSP-Greg]

@ioquatix

Re the MinGW SSL errors, MSYS2's OpenSSL uses a path relative to the exe file for the location of DEFAULT_CERT_FILE, DEFAULT_CERT_DIR, and DEFAULT_CONFIG_FILE. That isn't set up in the CI.

Hence, using OpenSSL::SSL::VERIFY_NONE may solve the issue. I haven't tested. Note that msvc/mswin OpenSSL builds typically use an absolute path for those locations.

[ioquatix]

@MSP-Greg thanks for the quick reply. I'll try using VERIFY_NONE. For testing purposes it's fine.