Eric Wong <normalperson / yhbt.net> wrote:
> hsbt / ruby-lang.org wrote:
> > - 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.

Thinking about this even more; I don't think it's possible to
preserve round-robin recv_io/accept behavior I want from
blocking on native threads when sharing descriptors between
multiple processes.

So a new class it is...

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

OK, I am liking "threadlet", and it looks like a real word:

https://www.merriam-webster.com/dictionary/threadlet
": a small thread : a delicate filament"

> >  * Lock and queue should work with auto-fiber?
> 
> I can definitely make Queues work.  I think ko1 was mildly
> against increasing use of Mutex.

How about we use Threadlet to discourage things we don't like
about normal Threads (such as Mutex, ConditionVariable, ...).

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

s/Fibers/Threadlets/; but yes, I think it should be possible
to have something like Threadlet.exclusive { ... } to prevent
auto-switch surprises (like Thread.exclusive in 1.8)

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