[pypy-dev] Syntax for the 'transaction' module

[Armin Rigo]

Hi Holger,

On Tue, May 1, 2012 at 16:48, holger krekel <holger at merlinux.eu> wrote:
> Maybe "atomic" could become a __pypy__ builtin and there could be a "ame" or
> so package which atomic-using apps could depend on? In any case,
> I really like the twist of "To remedy the GIL use AME" :)

Yes, indeed, a private name in the __pypy__ module looks fine.  The
applications are supposed to use the "ame" module or package (or
whatever name makes sense, but I'm getting convinced that
"transaction" is not a good one).  The "ame" module re-exports
__pypy__._atomic as ame.atomic for general use, but also offers more
stuff like the Runner class with add()/run() methods.

Also, again, it doesn't necessarily make sense to force a lexically
nested usage of ame.atomic, so we could replace __pypy__._atomic with
two primitives __pypy__._atomic_start and _atomic_stop, re-exported in
the "ame" module, and write the "ame.atomic" context manager in pure
Python.

> I am wondering how this all applies to the execnet-execution model, btw.
> (http://codespeak.net/execnet for those who wonder what i mean)
> remote_exec()s on the same gateway run currently in different threads
> and thus only send/receive needs to use "with atomic", right?

In my proposal, existing applications run fine, using multiple cores
if they are based on multiple threads.  You use "with atomic" to have
an additional degree of synchronization when you don't want to worry
about locks & friends (which should be *always*, but is still an
optional benefit in this model).  Maybe you're just talking about
simplifying the implementation of execnet's channels to use "with
atomic" instead of acquiring and releasing locks.  Then yes, could be,
as long as you remember that "with atomic" gives neither more nor less
than its naive implementation: "don't release the GIL there".


A bientôt,

Armin.