danieldasilvaferreira / gmail.com wrote:
> normalperson (Eric Wong) wrote:
> 
> > No, I'm against making major changes. For 2, I mean we limit
> usage to queues for now, which is a a subset of 1; but I'm also
> OK implementing mutex/condvar support for 1.
> 
> > Having less things to learn is better for adoption and improving
> usefulness
> 
> I would agree with that comment if the "less" doesn't imply in itself an overlap of confusions.
> How will be the documentation? We need to think very careful about that.

I prefer minimal documentation and having it do obvious/predictable
things which are already familiar to existing users of Thread.

In my experience, too much documentation overhwhelms users and
they ignore it.

And about the comments you see from developers here: the vast
majority of Ruby users will never read or see them even.
There's too much to read for most people.

> > Too obscure and not obvious for me; do non-Lua people know about it?
> 
> Do we have Threadlets in other languages?
> It seems Lua has got something very similar (how similar?) and calls it Lanes.
> Am I wrong with this assumption?

The "let" suffix is commonly associated with a smaller version
of something; and the "Thread" prefix already exists; so it
should be immediately familiar (at least to English speakers)

> > When comparing to physical objects, it seems more appropriate for
> something like a channel or pipe.
> 
> In a dedicated Lane I see "vehicles" moving steady and fast in between the traffic chaos.
> I consider it a fortunate choice from Lua people.
> The notion of async for me is management of traffic in between the chaos.
> Why thread? Because it is a kind of channel or pipe as well, isn't it?

Not exactly.  Pipes are a type of queue (ring buffer), it is
something which data passes through.  Threads/Processes/Fibers
are execution contexts which can use pipes/queues to pass data along.

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