[ruby-core:81089] Re: [ruby-cvs:65407] normal:r58236 (trunk): thread.c: comments on M:N threading [ci skip]

[Eric Wong <normalperson@yhbt.net>]

SASADA Koichi <ko1@atdot.net> wrote:
> Thank you.
> 
> (quote it first)
> > Do you have any deadlines or priorities?
> 
> No. I want to make clear your priority to avoid conflicts with me.

OK, good to know.

> On 2017/05/10 3:51, Eric Wong wrote:
> >> (1) lightweight fiber switching by pointer-exchange
> >>     (w/o copying context).
> > 
> > Out of all tasks here, I am least familiar with this (1).
> > This will be learning experience for me.
> > 
> >> (2) auto-fiber swiching
> >>    (2-1) implement with epoll/kqueue/select
> >>    (2-2) design APIs to use it
> > 
> > I think I will start on the select implementation first for
> > portability, but model our internal API around epoll(*).
> > I will probably implement epoll support last, since I am
> > most familiar with it.
> > 
> > (*) with current GVL, I expect our kqueue+kevent implementation
> >     will be faster than epoll in most cases (the API requires
> >     fewer syscalls).  select might be fastest with few FDs.
> 
> (1) and (2) are independent so that we can do it parallel.
> 
> Do you want to try (1) first or can I try (1)? Yes, Doing (1) is good to
> learn core internal, but maybe (1) affect many places in VMs. So I want
> to try. Anyway we should make new ticket and discuss on it.

You should do (1) first, you are the VM expert :)

> I guess (2) is not so easy to design APIs.

Lets keep changes to C-API internal and experiment, first.
First start with modifying rb_wait_for_single_fd() and
rb_waitpid() to be auto-Fiber-aware.  They will register event
watcher and call Fiber.yield instead of releasing GVL to sleep
when waiting.

Later, we can modify rb_thread_fd_select() and rb_thread_sleep*()
and maybe others.

> * We need to survey other languages

I will study the GHC IO manager, I think they are similar to my
vision of using EV_ONESHOT/EPOLLONESHOT with multi-core support:
http://haskell.cs.yale.edu/wp-content/uploads/2013/08/hask035-voellmy.pdf
(and also similar to what I used for cmogstored)

I do not know the Haskell language, so I will need to study it some.

> * We need to define blocking operations:
>   * blocking operation can switch Fibers automatically (I/O read, ...)
>   * blocking operation can switch Fibers automatically
>     (other than epoll/kqueue/select manage-able operations,
>      extra-C exts providing blocking operations, ...)

Basically, I want auto-Fiber to behave like 1.8 green threads,
but without timer-based switching.   Fiber switch should only
happen when operations cannot proceed (I/O, waitpid, sleep,
etc), or when user calls Fiber.yield.

>   And how to provide such difference to users?
>   * Idea: Documentation
>     * example: POSIX singal safe functions
>     * example: Java's thread-safety
>     Generally, it is hard to use because users should
>     them carefully (and usually people don't).
>   * Idea: Provide new APIs which support auto-fibers
>     (and other blocking operations don't support)
>     * example: EventMachine, ... (other language example? Python?)
>     * it is clear for users.
>     * it is hard to import existing code

Exactly, new APIs will take more time to adopt.  I don't think
it is necessary to introduce new IO APIs.  Currently, users
expect Thread switch when doing blocking IO (GVL release);
it should be easy to understand auto-Fiber switch if IO
would block (like 1.8 Thread)

Also, there is a NeverBlock RubyGem which made Fibers automatic
(like 1.8 threads), but development stopped years ago.

Ideally, I want existing code to be able to use net/* in stdlib
(and similar) with minimal modification: s/Thread.new/auto-Fiber.new/

>   * Idea: Provide a new TracePoint probe
>     to know blocking operation which does not support auto-fibers.
>     * This idea is for advanced user to check their scheduling
>     * I think it is enough because
>       * advanced user should be production maker.
>         Automatic tools are preferable.
>       * not advanced user don't care which operation can stop
>         forever w/o auto-fiber switching

Yes, we can add this once the auto-switch is implemented :)

> * We need to define auto-Fiber constructor

Perhaps that is a job for matz :)

> * ...
> 
> Ah, I remember that we have (2') providing epoll/kqueue like Ruby
> interface. (2) use them in scheduler internally and only auto-fibers use
> it. However, someone want to use them and want to write their own
> scheduler (like nodejs culture). I'm not sure we should expose such
> interface but it is valuable to consider. If we decide to provide such
> APIs, we need to share the implementation (or shouldn't?). Furthermore,
> it is more easy to provide such APIs compare with providing auto-fibers.

I don't think exposing new API is necessary, yet.  I prefer we
focus on internal implementation changes, first, and expose
user-visible changes later.

<snip>
 
> >> (4) Re-implement Queue (some days ago you wrote)
> > 
> > I already had some work-in-progress patches I can cleanup and
> > send out to redmine for review later (also ConditionVariable).
> > Last I remember, there was a small performance regression for
> > small Queue/Condvar waiter lists due to better locality on embed
> > structs.  However, I think avoiding O(n) rb_ary_delete behavior
> > is more important for busy queues.
> 
> OK.

Btw, that is [Feature #13552] - it might be ready.

> >> (please add your plan if you have others)
> > 
> > I might break out thread.c and io.c into smaller files
> > (select/epoll/kqueue/timer_thread/copy_stream/...)
> > to make code organization easier.
> 
> Not sure we can do it for io.c.
> Please ask someone else.

akr / nobu?