Home Original page

Stackless, thread paradigm and C extensions

Donn Cave donn at u.washington.edu
Tue Nov 13 12:19:55 EST 2001 
Quoth "Frederic Giacometti" <frederic.giacometti at arakne.com>:
| "Michael Hudson" <mwh at python.net> wrote in message
| news:uu1w0e0vo.fsf at python.net...
...
|> I must be missing something.  Can you sketch how, say, socket.send()
|> would be implemented?  Would you spawn a new OS thread for every C API
|> call?  I'm afraid I don't understand you to this point...
|
| As I mentioned, two thread pools would be maintained.
| To the extent that send() is reentrant on the underlying OS, it would
| beexecuted in one of the threads of the reentrant thread pool.
| This is the 'thread pool' pattern; where threads are kept up (i.e. active)
| from one call to the next. It's a standard pattern and concurrent
| programming algorithm.
|
| Of course, this requires a non-blocking thread library (i.e. with OS
| support); not a 'green thread' library (blocking, no OS support). Currently,
| Python is always build on non-blocking threads when they exist anyway.

But while it requires OS thread support, it collides with support of
OS threads, doesn't it?  For example, the threaded applications I write
use one thread per window, threads created by Window.Show().  Those
threads call back into the interpreter on window events, and the
interpreted code calls right back into the C level graphics library;
that library is built around this multi-threaded system and the calling
thread isn't something to select arbitrarily from a pool, it has to be
the thread that supports the Window object that noticed the event.

I can't tell if this proposal is really incompatible with that - maybe
a diagram would work better for me, too!

	Donn Cave, donn at u.washington.edu
More information about the Python-list mailing list