[Python-Dev] ActiveState & fork & Perl

[Guido van Rossum]

[Tim]
> Moving back in time ...
> 
> [GordonM]
> > Perhaps Christian's stackless Python would enable green threads...
> 
> [Guido]
> > This has been suggested before...  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!
> 
> I didn't understand this.  If I/O calls are left alone, and a green thread
> hit one, the whole program just sits there waiting for the call to complete,
> right?
> 
> But if the same thing happens using "real threads" today, the same thing
> happens today anyway <wink>.  That is, if a thread doesn't release the
> global lock before a blocking call today, the whole program just sits there
> etc.
> 
> Or do you have some other kind of problem in mind here?

OK, I'll explain.  Suppose there's a wrapper for a read() call whose
essential code looks like this:

	Py_BEGIN_ALLOW_THREADS
	n = read(fd, buffer, size);
	Py_END_ALLOW_THREADS

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
wrapped in library functions, e.g. gethostbyname() or fread().  Then,
you need to have a way to implement sleep() by talking to the thread
schedule (remember, this is the thread scheduler we have to write
ourselves).  Oh, and of course the thread scheduler must also have a
select() lookalike API so I can still implement the select module.

Does this help?  Or am I misunderstanding your complaint?  Or is a
<wink> missing?

--Guido van Rossum (home page: http://www.python.org/~guido/)