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

[SASADA Koichi <ko1@atdot.net>]

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.

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.


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

* We need to survey other languages

* 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, ...)

  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
  * 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

* We need to define auto-Fiber constructor

* ...

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.



>> (3) Implement GVL with futex (in your comment)
> 
> Maybe last.  Linux-only, single (but most important)
> platform; and the single CPU regression needs to be fixed.

Cool.

>> (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.

> 
>> (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.

> Also, I will try not to break platforms I don't use.  As you
> know I only use Free Software, so I would appreciate if you or
> platform maintainers can help fix portability bugs on non-Free
> systems.

Absolutely.

-- 
// SASADA Koichi at atdot dot net