[pypy-dev] multiple isolated VMs in a single process

holger krekel hpk at trillke.net
Fri Feb 7 19:49:59 CET 2003


[Tobias Oberstein Fri, Feb 07, 2003 at 07:09:48PM +0100]
> Are there any design plans regarding threading architecture yet?

good question.

> I particular, are you planning to support having multiple
> interpreters in one process _without_ sharing objects (no free
> threading but VM-wise locking). Supporting this would require
> early design decisions like
> 
>  - no global data for the interpreter/VM
>  - no global data in object implementations
>  - but what about extension modules? many have global data ..
> 
> isn't it? Also, in an  C embedding API, will the VM-state be
> take from thread-local storage or passed into every function
> by the embedding application via an opaque pointer?

IMO we should defer this specific question to a later point.  I don't
expect a C-API to PyPython any time soon. We probably will go for
a python-only system first.  At least i wouldn't consider 
backward-compatibility to CPython's C-API a mandatory feature.
We might as well run on ObjC for that matter :-)

> I'm thinking of embedding a dynamic language into an
> multithreaded OODBMS. The different VMs within the server process
> would share data via objects instantiated from a special
> extension class that wraps up the OODBMS. Synchronisation on
> these objects is taken care of by the OODBMS. No need to share
> objects local to each VM.

A valid use case, IMO.  although some people would say
that you might use ZODB which does it with multiple 
processes.   To me the biggest point for using processes 
is stability.  It does come at a cost, though.  You have 
to deal with "copies" of objects and only have "shared" 
objects at a higher level.  This might suit your needs, though. 

> Sadly, as I was told, fixing above issues for CPython would
> be hard like shit. It's so sad that global data has not been
> avoided from the very beginning in the CPython.

I am sure we will try to avoid global data structures. 
We are all good and nice programmers, aren't we? :-)

Tobias, would you mind going to our issue-tracker

    http://codespeak.net/issues/pypy/

registering yourself and posting your "issue" as a
"wishlist" item?  This way we are sure not to loose
valuable suggestions and use cases. 

Better yet, join the upcoming sprint right next door :-)

thanks,

    holger


More information about the Pypy-dev mailing list