Stackless, thread paradigm and C extensions

[Frederic Giacometti]

"Michael Hudson" <mwh at python.net> wrote in message
news:uzo5pl5g4.fsf at python.net...
> "Frederic Giacometti" <frederic.giacometti at arakne.com> writes:
>
> > "Michael Hudson" <mwh at python.net> wrote in message
> > news:u8zdaodu4.fsf at python.net...
> > > "Frederic Giacometti" <frederic.giacometti at arakne.com> writes:
> [...]
> > > 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...
> >
> > A possible implementation would consist in using the method flag to mark
C
> > python methods/functions to run outside the interpreter thread. This
way,
> > the entire function runs in a separate thread.
>
> method flag?

The 3rd field of the PyMethodDef structure (the one on which METH_VARARGS is
used...)

FG