[ruby-core:88486] Re: [Ruby trunk Feature#13618] [PATCH] auto fiber schedule for rb_wait_for_single_fd and rb_waitpid

[e-mail] wrote:
> [e-mail] wrote:
> 
> > I am thinking of adding preemption support to this feature for
> compatibility with 1.8
> 
> non-preemptive vs preemptive.
> coroutines are non-preemptive.
> threads are preemptive.
> Are we talking about having the two behaviours in this new feature?

"Preemptive" is a minor detail, here.  I don't care that much about
it; it is a single bit flag we can implement at a later time.

> > So this made me think of "Thread::Coro"
> 
> What is the logic behind "Coro"?

Short for "Coroutine".

> > Other ideas: Thread::CSP or Thread::Sequential (probably too long)
> 
> Does it mean we will have the CSP algebraic operators available?

No, so probably "CSP" is not a good name for this.  I am not a
formal nomenclature person; I make engineering decisions which
are ultimately sympathetic to:

a) compatibility with existing codebases
b) hardware limitations

> Reading through this conversation it feels we are dealing with a feature with a lot of concepts incorporated into it.
> Can we get a resume of all the functionality we expect to have?

It shouldn't be any different than how Ruby threads are currently used.
Only creation is different:

	"Thread.new {}" vs "Thread::Coro.new {}"

> Or even feature comparison with other languages.

I don't know feature details of other languages well enough to
comment.  Basically, this is re-introduction of green threads
from Ruby 1.8; but I still want to keep benefits of 1.9-2.5
native threads.

See my other reply to ko1 in this thread [ruby-core:88484] for
pros/cons of both:
http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-core/88484
 (or <https://public-inbox.org/ruby-core/20180814174702.GA32360@dcvr/>)

However, I don't know other languages (Haskell/GHC, Go, Erlang)
well enough to describe APIs; but I know they have lightweight
threads (M:N) which use less memory than native 1:1 threads.

What I don't like about transparent M:N threading is (AFAIK for
those languages) they don't give programmers a choice about when
to use native vs green.  M:N threading is fine when you want
parallelism in SMP because timeslices are predictable when
your bottleneck is CPU/memory on SMP systems.

Implementations of M:N falls down when you want parallelism
across multiple filesystems because timeslices become
unpredictable.  This is a problem for low-end SSDs and HDDs
especially, but also network filesystems and USB sticks.

Making the Ruby VM transparently aware of multiple filesystems
and bottlenecks/characteristics of each mountpoint may be
out-of-scope.  I'm not aware of any language runtime takes that
into account; so we can leave that to the Ruby user.

Also, C Ruby generally sucks at taking advantage of SMP
because of GVL.  However, we are currently great at dealing
with parallelism across multiple filesystems because of
1:1 threads.

> I believe we must do that kind of documentation to show to the community in a clear way the new ruby async possibilities.
> I'm willing to help in planning and developing it.

The goal is to make migration/testing easy and minimize rewrite
cost.  So programmers can gsub(/\bThread\.new\b/, "Thread::Coro.new")
in places where only 1:N threads make sense (see [ruby-core:88484])

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