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

[Tim Peters]

[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