Stackless, thread paradigm and C extensions
Frederic Giacometti
frederic.giacometti at arakne.com
Wed Nov 14 21:39:56 EST 2001
"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
More information about the Python-list
mailing list