[PEAK] Reactor-driven microthreads

[Phillip J. Eby]

At 04:06 PM 12/31/03 -0500, Ty Sarna wrote:

> >      events.Thread           (triggers when thread is finished running)
>
>ThreadExit or WaitForThread or something like that would be more clear.
>yield events.Thread(...) sounds too much like I'm yielding *to* a specific
>thread, rather than having it yield to me :-)

Okay.  Instead, we'll have Thread objects have a 'finished' Value on them, 
that they set upon completion.  Then, to wait for 'aThread' to finish, you 
would say:

     yield aThread.finished

:)


> > resume()  (I'm actually tempted to make this a primitive or at least 
> export
> > it from peak.api)
>
>Hmm, yes. given how often it's likely to be used...

OTOH, events.resume() isn't *too* terrible.  We'll see what other folks say.


> > the whole thing would be a lot clearer, although the lack of try-finally
> > might be occasionally inconvenient.
>
>That kind of scares me, but then I can only find one daemon that uses them.

On the bright side, 2.4 may allow try-finally in generators, by executing 
the finally clause when the generator is deallocated, if it wasn't already run.


>Actually, it seems like it might be a bigger issue in the persistent
>workflow case.

Which actually isn't going to happen, anyway, because of issues with 
pickling code objects and versioning of workflows.  (Yes, I know we just 
talked about this in person, I'm just catching everybody else up.  :) )