Hi Andrew, On Fri, Feb 17, 2012 at 20:26, Andrew Francis <[email protected]> wrote: > 1) I have been looking at the transaction module and its dependent modules. > In rstm.perform_transaction, I see a comment to a "custom GIL." So the GIL > is still there? Or will it be eventually removed?
That's for tests. It's protected under "if not we_are_translated()", which means that this code is never translated into the final pypy executable. > I admit I am not comfortable with reading the code. However I see places > where the code distinguishes between mutable and immutable, local and non > local variables. I will assume mutable and non-local variables will be the > subject of transactional memory. Yes, exactly. But note that distinguishing such variables only occurs in RPython, where some fields of some objects are marked as "immutable". It is important because e.g. we don't want to track the reads of the integer value out of the immutable "int" objects. I suspect that it is less important at the level of regular Python, but see below. As for the difference between "local" and "global", it's also visible at RPython level only. If a transaction allocates an object, it is "local". If it reads from an object that existed before, it reads from a "global" object. If it writes to an object that existed before, the global object is first copied as a local object. (The global objects are immutable at this level.) When the transaction commits, we do a local GC and copy the surviving local objects to become globals; then we atomically update the global objects that have been copied and modified. This is, of course, all invisible at the level of Python. > can I assume that one can "help" the STM if a) somehow more > variables can be marked as immutable? This might maybe at some point later be exposed to Python level too, where if you would declare some fields of some Python class as being immutable; then you really couldn't change them but the implementation could improve a bit performance. But that's a language extension, so a bit unlikely to occur. > 2)"Threads of execution" do not share state. > Essentially a more functional programming approach. Well, multiple "threads of execution" do share state, in this programming model. It allows us to not have to completely change everything in the programs we already wrote. :-) > 3) Could the stackless module work with STM? Yes: one transaction would be the time between two switch()es. It would probably just need some integration between the existing modules, 'transaction' and '_continuation'. A bientôt, Armin. _______________________________________________ pypy-dev mailing list [email protected] http://mail.python.org/mailman/listinfo/pypy-dev
