Stackless, thread paradigm and C extensions

[Frederic Giacometti]

"Michael Hudson" <mwh at python.net> wrote in message
news:uu1w0e0vo.fsf at python.net...
> "Frederic Giacometti" <frederic.giacometti at arakne.com> writes:
>
> > "Michael Hudson" <mwh at python.net> wrote in message
> > news:u4ro58kzx.fsf at python.net...
> > > "Frederic Giacometti" <frederic.giacometti at arakne.com> writes:
> > >
> > > [schnipp]
> > > > Does this make sense?
> > >
> > > But isn't the point of many multithreaded apps allowing code to run
> > > during blocking IO operations?  Your approach would knock that on the
> > > head.
> >
> > In the proposed design, stackless call to another thread never
> > blocks the thread; it inserts a frame in one of the thread frame
> > schedulers.  Just as all C functions external to the Python
> > interpreter core, IO functions run outside the interpreter thread.
>
> 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.

FG