On Thu, Jul 29, 2010 at 7:18 AM, William Leslie <[email protected]> wrote: > On 29 July 2010 11:33, Kevin Ar18 <[email protected]> wrote: >> In detail, here's what I mean: >> * unlike POSH, utilize OS threads and shared memory (not processes) >> * Create a special shared memory location where you can place Python objects >> * Each Python object you place into this location can only be accessed >> (modified) by 1 thread. >> * You must manually assign ownership of an object to a particular thread. >> * The thread that "owns" the object is the only one that can modify it. >> * You can transfer ownership to another thread (but, as always only the >> owner can modify it). > > When an object is mutable, it must be visible to at most one thread. > This means it can participate in return values, arguments and queues, > but the sender cannot keep a reference to an object it sends, because > if the receiver mutates the object, this will need to be reflected in > the sender's thread to ensure internal consistency. Well, you could > ignore internal consistency, require explicit locking, and have it > segfault when the change to the length of your list has propogated but > not the element you have added, but that wouldn't be much fun. The > alternative, implicitly writing updates back to memory as soon as > possible and reading them out of memory every time, can be hundreds or > more times slower. So you really can't have two tasks sharing mutable > objects, ever. > > -- > William Leslie
Hi. Do you have any data points supporting your claim? Cheers, fijal _______________________________________________ [email protected] http://codespeak.net/mailman/listinfo/pypy-dev
