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

SASADA Koichi <[e-mail]> wrote:
> On 2017/04/02 11:35, Eric Wong wrote:
> > However, to spawn native threads:
> > 
> > If a Thread uses existing GVL release C-API, then the _next_
> > Thread.new call will create a native thread (and future
> > Thread.new will be subclass of Fiber in new native thread).
> > 
> > So, in pseudo code:
> > 
> >   class Thread < Fiber
> >     def self.new
> >       case Thread.current[:gvl_state]
> >       when :none
> >          # default
> >          super # M += 1
> >       when :released
> >         # this is set by BLOCKING_REGION GVL release
> >         # only allow a user-level thread to spawn one new native thread
> > 	Thread.current[:gvl_state] = :spawned
> > 
> >         NativeThread.new { Thread.new } # N += 1
> >       when :spawned
> >         # We already spawned on native thread from this user-level
> > 	# thread, only spawn new user-level thread for now.
> > 	super # M += 1
> >       end
> >     end
> >   end
> > 
> > Current GVL release operations will change
> > Thread.current[:gvl_state] from :none -> :released
> 
> Sorry I can't understand the basic of your idea with mixing Threads and
> Fibers. Maybe you need to define more about the model.

Sorry if I wasn't clear.  Basically, I see:

	green Threads == Fibers + auto scheduling

So, making Threads a subclass of Fibers makes sense to me.
Then, existing (native) threads becomes an own internal class
only accessible to C Ruby developers; new native threads get
spawned as-needed (after GVL releases).

> Our plan is not mixing Threads and Fibers, so that (hopefully) there are
> no problem.

OK, I will wait for you and see.

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