hsbt / ruby-lang.org wrote:
> We discussed your proposal at last developer meeting (Dec 26, 2017)

Awesome news.

> - Name this "Thread", or something Thread-ish word than Fiber-ish

So if we just use "Thread", then existing Thread becomes M:N?
I will think about that...  I have many use cases for native
threads, too; but maybe they can be satisfied transparently.

> - Matz doesn't have a strong opinion on the name but prefers 2 words (auto-fiber) than a coined word "Thriber."
> 
> Next actions:
> 
>  * Give a thread-ish name

OK, naming is hard :<

LightThread?  Maybe too long...

Threadlet?

Not Thread-ish, but "Task"(*) or "Tasklet" may be a candidate.

This might take a while....

>  * Lock and queue should work with auto-fiber?

I can definitely make Queues work.  I think ko1 was mildly
against increasing use of Mutex.

One safety feature I was thinking about was disabling
auto-switching of Fibers while a Mutex is locked, even.

>  * Is explicit context switching onto auto-fiber possible?

Yes, right now it's a subclass of Fiber so inherits
transfer/resume/yield



(*) Linux kernel uses "task" as generic term for threads, processes,
    and everything in-between (different flags describe level of
    sharing for clone(2))

Unsubscribe: <mailto:ruby-core-request / ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>