Hi Holger, On Tue, May 1, 2012 at 16:48, holger krekel <hol...@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. _______________________________________________ pypy-dev mailing list pypy-dev@python.org http://mail.python.org/mailman/listinfo/pypy-dev
