Stackless, thread paradigm and C extensions

Michael Hudson mwh at
Tue Nov 13 17:06:39 CET 2001

"Frederic Giacometti" <frederic.giacometti at> writes:

> "Michael Hudson" <mwh at> wrote in message
> news:uu1w0e0vo.fsf at
> > 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.

So when Python code executes


the interpreter would take a thread form the pool, and in effect say
"here, run this function".  Then the interpreter thread would go off
and execute pending Python threads, and when the sock.recv call
returned, it would add the thread that called it back to the set of
pending interpreter threads?  (I think this would be easier to discuss
with paper and pencil...)

What does this buy us again?  It still makes writing C code that calls
Python code a bit of a pain, doesn't it?  Oh, maybe not.  More
thinking required...


  The meaning of "brunch" is as yet undefined.
                                             -- Simon Booth,

More information about the Python-list mailing list