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