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

[Guido van Rossum]

> [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]

[Tim responds, explaining that without this threads are quite useful.]

I guess it's all in the perspective.  99.99% of all thread apps I've
ever written use threads primarily to overlap I/O -- if there wasn't
I/O to overlap I wouldn't use a thread.  I think I share this
perspective with most of the thread community (after all, threads
originate in the OS world where they were invented as a replacement
for I/O completion routines).

(And no, I don't use threads to get the use of multiple CPUs, since I
almost never have had more than one of those.  And no, I wasn't
expecting the read() to be fed from another thread.)

As far as I can tell, all the examples you give are easily done using
coroutines.  Can we call whatever you're asking for coroutines instead 
of fake threads?

I think that when you mention threads, green or otherwise colored,
most people who are at all familiar with the concept will assume they
provide I/O overlapping, except perhaps when they grew up in the
parallel machine world.  Certainly all examples I give in my
never-completed thread tutorial (still available at
http://www.python.org/doc/essays/threads.html) use I/O as the primary
motivator -- this kind of example appeals to simples souls
(e.g. downloading more than one file in parallel, which they probably
have already seen in action in their web browser), as opposed to
generators or pipelines or coroutines (for which you need to have some 
programming theory background to appreciate the powerful abstraction
possibillities they give).

Another good use of threads (suggested by Sam) is for GUI programming.
An old GUI system, News by David Rosenthal at Sun, used threads
programmed in PostScript -- very elegant (and it failed for other
reasons -- if only he had used Python instead :-).

On the other hand, having written lots of GUI code using Tkinter, the
event-driven version doesn't feel so bad to me.  Threads would be nice
when doing things like rubberbanding, but I generally agree with
Ousterhout's premise that event-based GUI programming is more reliable
than thread-based.  Every time your Netscape freezes you can bet
there's a threading bug somewhere in the code.

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