On Sat, 2009-11-21 at 09:35 -0500, Gary Robinson wrote: > OK, thanks for the confirmation that it's not working yet, and letting me > know what it would take! > > I wish we had the resources to take on the task of converting it to > RPython, but there's no way at this point. :) I'm using pyprocessing > with unladen swallow now and it works fine but for the kinds of things > we're doing (mathy floating point stuff) I'd expect more speed from > PyPy...
The C component of multiprocessing, at least in python 2.6 is tiny and trivial: a read and write implementation for the underlying connection class. It would probably be better off converted to plain python for pypy in any case. On Sat, 2009-11-21 at 15:06 +0100, Maciej Fijalkowski wrote: > Oh, and by the way, personally I would prefer to kill the GIL, so we > don't have to worry any more (but also noone from core devs is working > on it). > What, roughly, would be required to remove pypy's gil? I have heard rather nebulous tales of woe and tribulation on the cpython lists referring to fine-grained per-object locking, re-entrant garbage collectors, abi stability, and other horrors. I have no idea what bits of this dubious information would be relevant to pypy's rather more abstract internals, however. -Terrence _______________________________________________ [email protected] http://codespeak.net/mailman/listinfo/pypy-dev
