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

[Christian Tismer]

Guido van Rossum wrote:

> [Guido and Tim, different opinions named misunderstanding :]
> 
> 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 don't think this would match it.
These threads can be implemented by coroutines which always
run apart, and have some scheduling running.

When there is polled I/O available, they can of course
give a threaded feeling. If an application polls the
kbhit function instead of reading, the other "threads"
can run nicely.
Can be quite useful for very small computers like CE.

Many years before, I had my own threads under Turbo Pascal
(I had no idea that these are called so). Ok, this was
DOS, but it was enough of threading to have a "process"
which smoothly updated a graphics screen, while another
(single! :) "process" wrote data to the disk, a third one
handled keyboard input, and a fourth drove a multichannel
A/D sampling device.

? Oops, I just realized that these were *true* threads.
The disk process would not run smooth, I agree. All
the rest would be fine with green threads.

...
> 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.

Right. But with a traceback instead of a machine hang,
this could be more attractive to do. Green threads/coroutines 
are incredibly fast (one c call per switch). And since they have
local state, you can save most of the attribute lookups which
are needed with event based programming.
(But this is all theory until we tried it).

ciao - chris

-- 
Christian Tismer             :^)   <mailto:tismer at appliedbiometrics.com>
Applied Biometrics GmbH      :     Have a break! Take a ride on Python's
Kaiserin-Augusta-Allee 101   :    *Starship* http://starship.python.net
10553 Berlin                 :     PGP key -> http://wwwkeys.pgp.net
PGP Fingerprint       E182 71C7 1A9D 66E9 9D15  D3CC D4D7 93E2 1FAE F6DF
     we're tired of banana software - shipped green, ripens at home