[ruby-core:90141] Re: [Ruby trunk Feature#13618] [PATCH] auto fiber schedule for rb_wait_for_single_fd and rb_waitpid

[Eric Wong <normalperson@yhbt.net>]

samuel@oriontransfer.net wrote:
> @k0kubun I like the general ideas presented here but the
> implementation is too heavy/specific for my use case. For
> example, it won't work on JRuby, TruffleRuby, or other
> implementations. That's the major benefit of using a gem for
> the reactor implementation.

Fiber doesn't really benefit (in terms of memory use) on JRuby,
either, right?  I don't know much about implementations outside
of this one.

> Additionally, I need to use Fiber for task switching. Does
> `Thread::Light` allow `yield`/`resume`?

We can expose yield/resume easily; but I don't know if there
is use case for it...  There is already Kernel#sleep support
and Thread::Light#run

Maybe a Thread::Light#raise implementation?  I don't know if
interrupts should be handled via rb_thread_t or
rb_execution_context_t (right now, it's mixed and confusing)

> The tricky part about supporting a different backend is
> whether it changes semantics of operations. If it does, it's a
> big problem.

What semantic changes are you talking about?  I'm doing
my best to make things transparent to native Thread users.

The biggest difference is waitpid probably won't benefit on
Windows because lack of SIGCHLD (maybe @usa can workaround it
with polling or IOCP).

> If you try to use two different libraries of code
> that expect different backend semantics, it can cause many
> headache. That's why I think as an IO reactor, this is really
> great, but as a high level interface, I'm not convinced I can
> use it.

Really, stop thinking in terms of "reactor".  It does not map
well to applications requiring many native threads (as I've said
this many times, already).

There is no reactor for this and never will be.
Instead, the scheduling mechanism wires into kernel-provided
queues (e.g. "kqueue", I've said this before, too).