Fake threads (was [Python-Dev] ActiveState & fork & Perl)

[Gordon McMillan]

I've been out of town, too (not with Skip), but I'll jump back in 
here...

[Guido]

> When the read() call is made, other threads can run.  However in
> green threads (e.g. using Christian's stackless Python, where a
> thread switcher is easily added) the whole program would block at
> this point. The way to fix this is to have a way to tell the
> scheduler "come back to this thread when there's input ready on
> this fd".  The scheduler has to combine such calls from all
> threads into a single giant select. It gets more complicated when
> you have blocking I/O

I suppose, in the best of all possible worlds, this is true. But I'm 
fairly sure there are a number of well-used green thread 
implementations which go only part way - eg, if this is a 
"selectable" fd, do a select with a timeout of 0 on this one fd and 
choose to read/write or swap accordingly. That's a fair amount of 
bang for the buck, I think...

[Tim]
> Threads can be very useful purely as a means for algorithm
> structuring, due to independent control flows. 

Spoken like a true schizo, Tim me boyos! Actually, you and Guido are 
saying almost the same thing - threads are useful when more than one 
thing is "driving" your processing. It's just that in the real world, 
that's almost always I/O, not some sick, tortured internal 
dialogue...

I think the real question is: how useful would this be on a Mac? On 
Win31? (I'll answer that - useful, though I've finally got my last 
Win31 client to promise to upgrade, RSN <hack, cough>).


- Gordon