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

Tobias Oberstein Tobias.Oberstein at gmx.de
Tue Feb 11 00:00:46 CET 2003


> On Fri, 2003-02-07 at 16:33, Tobias Oberstein wrote:
> > > > > 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.
>
> This is a bit off-topic, but I wanted to clarify about ZODB.  ZODB does
> allow a multi-threaded application to use multiple database
> connections.  Each connection is associated with a thread and gets in
> independent / isolated view of the database.

Just to be sure: last time I read into ZODB I learned that ZODB does
multi-versioning with optimistic concurrency control at the object level.
Associated with every database connection is an object cache (to provide
the isolated view). So on object access, data has to be copied (in-process)
from the storage core to the object cache of the specific database
connection.

> This approach has the
> costs you mention -- multiple copies of objects in particular -- but
> sharing is a bit cheaper because method calls replace IPC.

Right, but if you want to scale on SMPs (which, I admit, is not the
most common case and certainly debatable on its own) situation, the often
heard advice is to use ZEO, which

i) requires some form of IPC (for ZODB<->ZEO, is there anything like
shared-memory connection? It uses TCP/IP, even if both ZEO and ZODB's
are on the same host, isn't it?)

ii) uses broadcasts from ZEO to all the ZODBs to invalidate touched
objects, which doesn't scale for write intensive apps

If one does not use ZEO, but runs ZODB as a single process multi-threaded
process on the other hand, scaling on SMPs will be limited by the global
interpreter lock of CPython. Of course, this is an implementation issue
with CPython.

Fixing the GIL issue with CPython once and forever would not be too hard
(see attached idea sketch). However as I was told, fixing the GIL issue
would have to get enough votes to become core. I'm not feeling in a position
to collect them in the Python community .. guess I'm an outsider on all
measures;) So I moved on looking for other means.

Enter PyPy. There's a chance that PyPy does not repeat design flaws like
relying heavily on global state and stuff. Great.

Currently I'm even considering completely different VMs like from the Mono
project or from the Portable.NET project. I want to intergrate a VM with
a OODBMS and do that right. That's _my_ focus.

Tobias
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: PyWorld_PEP.txt
URL: <http://mail.python.org/pipermail/pypy-dev/attachments/20030211/684217e7/attachment.txt>


More information about the Pypy-dev mailing list