[dmd-concurrency] draft 3

Andrei Alexandrescu andrei at erdani.com
Mon Jan 11 14:22:36 PST 2010


You're dead on.

I'm thinking of solving that problem through two mechanisms:

a) A deepCopy protocol. deepCopy(value) will create a copy of value that 
shares absolutely nothing with the original value. The type system won't 
be able to always ensure that, so we'll need to rely on the user to 
implement it properly. With deepCopy in place, UniqueArray works great - 
all you have to do is return a deepCopy() of the requested element. That 
way the addresses of the elements or their fields etc. never escape.

b) A serialization protocol. When doing IPC/IMC (M = machine) we'll need 
to serialize and deserialize objects into streams of bits. deepCopy 
can't help there.

We could solve both problems with (b) because deserializing a bitcopy 
will by necessity create a deep copy (you can't serialize a 
reference/pointer). But I'm still willing to define deepCopy because it 
seems silly to serialize/deserialize objects if all I want is to pass 
them to another thread.


Andrei

Sean Kelly wrote:
> On Jan 11, 2010, at 12:30 PM, Andrei Alexandrescu wrote:
>> Any implementation difficulties anyone is seeing so far?
> 
> The trick will be safely passing structured types containing references.  Initially we could simply forbid this, but we'll have to deal with it for serialization eventually.  I haven't run into any problems spawning threads using the new approach, passing messages via copying, etc though.  I expect once I start adding "shared" to the implementation I'll find myself wishing for tail-shared (for performance reasons, in instances where I know the reference isn't shared), so perhaps I should try that soon.
> _______________________________________________
> dmd-concurrency mailing list
> dmd-concurrency at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-concurrency


More information about the dmd-concurrency mailing list