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

[e-mail] wrote:
> I like Task a lot, it is short and makes much sense. 

I guess there's a risk of namespace conflict with existing
code with such a generic name like "Task" or "Job".  But,
maybe the class name should not matter as much as adding
new ones can always cause conflict with existing code.

So, based on your add_task proposal; maybe the name of the
class wouldn't even matter, and we can use whatever name,
(I just chose "async") to create it:

	foo = Thread.current.async do
	   # some task
	end

	foo.class => RubyVM::ThingWeCannotDecideANameFor

	# (Or Thread.async, because only current is supported atm)
	foo = Thread.async {}

	foo.class => RubyVM::ThingWeCannotDecideANameFor

In other words, API for usage and class name can be orthogonal.

> So conceptually a kernel thread will be allowed to schedule N Tasks. 

Right.

> How would you manage scheduling tasks that are potentially
> blocking. Should Ruby opt for a goroutine type implementation
> where core just handles spawning "enough" underlying threads
> to handle the work, or would the management be at a higher
> level and you would spawn N threads and then tasks from said
> threads.

That would be M:N threading which I am uncertain about.

Mainly, I want to still be able to do real blocking operations
even when non-blocking operations are supported for sockets:

  http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-core/85082
  https://public-inbox.org/ruby-core/[e-mail]/

  (likewise with recv_io or small IO#sysread on IO.pipe)

So "enough" is difficult to determine (not just CPU count).
I have use cases which involve multiple mount points which
I'd like to be able to optimize for with Ruby.

> I think it probably makes sense to always have Tasks coupled
> tightly with threads initially cause debugging will be much
> simpler.

Yes, it's a requirement at the moment since migrating Fibers
across Threads is not possible.

I think we'd have to give up fast native Fiber switching
(ucontext_t) if we want to migrate Fibers across Threads (maybe
ko1 can confirm).

So that's why "rb_thread_t.afrunq" came to be:

> > Changes to existing data structures:
> > 
> >     rb_thread_t.afrunq   - list of fibers to auto-resume

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