[Tim, claims not to understand Guido's
While this seems possible at first, all blocking I/O calls would have to be redone to pass control to the thread scheduler, before this would be useful -- a huge task!
] [Guido replies, sketching an elaborate scheme for making threads that are fake nevertheless act like real threads in the particular case of potentially blocking I/O calls]
... 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 [very painful <wink>]. ... Does this help? Or am I misunderstanding your complaint? Or is a <wink> missing?
No missing wink; I think it hinges on a confusion about the meaning of your original word "useful". Threads can be very useful purely as a means for algorithm structuring, due to independent control flows. Indeed, I use threads in Python most often these days without any hope or even *use* for potential parallelism (overlapped I/O or otherwise). It's the only non-brain-busting way to write code now that requires advanced control of the iterator, generator, coroutine, or even independent-agents-in-a-pipeline flavors. Fake threads would allow code like that to run portably, and also likely faster than with the overheads of OS-level threads. For pedagogical and debugging purposes too, fake threads could be very much friendlier than the real thing. Heck, we could even run them on a friendly old Macintosh <wink>. If all fake threads block when any hits an I/O call, waiting for the latter to return, we're no worse off than in a single-threaded program. Being "fake threads", it *is* a single-threaded program, so it's not even a surprise <wink>. Maybe in your Py_BEGIN_ALLOW_THREADS n = read(fd, buffer, size); Py_END_ALLOW_THREADS you're assuming that some other Python thread needs to run in order for the read implementation to find something to read? Then that's a dead program for sure, as it would be for a single-threaded run today too. I can live with that! I don't expect fake threads to act like real threads in all cases. My assumption was that the BEGIN/END macros would do nothing under fake threads -- since there isn't a real thread backing it up, a fake thread can't yield in the middle of random C code (Python has no way to capture/restore the C state). I didn't picture fake threads working except as a Python-level feature, with context switches limited to bytecode boundaries (which a stackless ceval can handle with ease; the macro context switch above is "in the middle of" some bytecode's interpretation, and while "green threads" may be interested in simulating the that, Tim's "fake threads" aren't). different-threads-for-different-heads-ly y'rs - tim