Hi Russel, On Sun, Sep 30, 2012 at 11:10 AM, Russel Winder <rus...@winder.org.uk> wrote: > However we want to get > away from a reliance on multiprocessing since it is rather heavyweight > for the sort of parallelism we are after. STM as an infrastructure layer > in PyPy and CPython would get us away from the GIL and allow for using > Python threads bound to kernel threads to allow a single Python process > to allow us to create lighweight processes (no application level shared > memory).
I'm not really sure I follow you exactly. You want to have 'multiprocessing' using OS threads and no shared memory, rather than using processes? That looks like it will have the same amount of overhead to me. But anyway, if that's what you want, then I don't understand where STM comes into the picture. STM is a trade-off solution: you get *shared* memory concurrency, possibly with easier models than threads to program with, against some high but fixed overhead. If your starting point is no shared memory, then STM makes little sense. If you just want several independent Python interpreters in the same OS process, then it is probably possible with some small amount of hacking in either CPython or PyPy. A bientôt, Armin. _______________________________________________ pypy-dev mailing list pypy-dev@python.org http://mail.python.org/mailman/listinfo/pypy-dev
