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