Stackless, thread paradigm and C extensions

[Michael Hudson]

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

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

So when Python code executes

   sock.recv(data)

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

Cheers,
M.

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