sam.saffron / gmail.com wrote:
> I like ThreadTask a lot since these things are coupled with
> threads. I think ThreadJob works as well. 

Maybe we can call it what it is:  Thread::Green

I suspect using top-level namespace is unnecessary and may
introduce conflicts.

> API wise we can even avoid this altogether with
> 
> Thread.current << lambda {  }
> 
> So we don't even need to think about async vs add_task vs add_job

I like that.

One question, is how will Thread#[]/#[]= be handled inside
the lambda?

> > Yes, it's a requirement at the moment since migrating Fibers
> > across Threads is not possible.
>
> I would like to hear a bit more about this, could there be an
> "expensive" thread transfer operator added perhaps that only
> moves when the fiber once suspended? 

One problem is the act of suspending it (Fiber.yield)
will need to change.  Maybe it could default to fast suspend,
and the migrate operation would:

	1. set a flag to indicate migration in progress
	2. resume
	3. see + clear migration flag
	4. suspend again immediately, but slowly for migration

But it's a totally orthogonal issue to auto-fiber

/me goes back to working on non-Ruby stuff...

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