[PEAK] Reactor-driven microthreads

[Ty Sarna]

> Any objections to adding 'peak.events' as a framework API?  That is, 'from 

Not wild about "events", but I have no counterproposal...

Heh, maybe "untwist"?

>      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 :-)

> 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...

> 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.

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