Home Original page

Stackless Platform Independence?

Frederic Giacometti frederic.giacometti at arakne.com
Sun Mar 3 16:47:41 EST 2002 
Aahz Maruch wrote:

> In article <I7Qd8.66687$dG.27729291 at news1.rdc1.sdca.home.com>,
> Frederic Giacometti <frederic.giacometti at arakne.com> wrote:
> >
> >In addition to all the benefits that Christian has described so far,
> >stackless python would make it possible to have a different OS
> >multi-threading implementation for calling external C/C++ libraries; one
> >that does not require interpreter lock operations.
> >
> > [...]
> >
> >Stackless just means that function calls executed by the bytecode are
> >executed by a C function that returns immediately; thus disconnecting
> >the C call stack from the virtual machine call stack.  In current
> >python, they are interleaved one-on-one; making it impossible to switch
> >context within the VM unnless you do Christian's last 'non-portable'
> >assembly language manipulation.
>
> How's that again?  In the absence of pre-emptive thread scheduling, what
> good is the immediate return from the C function?  More than that, how
> can you possibly call external libraries without the interpreter lock,
> if those libraries have any access to Python variables?  If they *don't*
> have access to Python, how is that any different from just using the
> macros Py_BEGIN_ALLOW_THREADS and Py_END_ALLOW_THREADS?

Just reverse the paradigm: have the python VM run in a single thread, using
stackless microthreads for python multithreading, and run the C calls in a pool of
threads.
This way: no lock is needed, since only one thread runs the VM, with the help of
microthreads, and C calls run in other threads.

FG
More information about the Python-list mailing list