[dmd-concurrency] draft 3

Benjamin Shropshire benjamin at precisionsoftware.us
Mon Jan 11 21:24:02 PST 2010


Andrei Alexandrescu wrote:
> 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.

Someone should look at ways to make implement deepCopy and 
serialize/deserialize via a single source. Both amount to "Walk this 
tree and render it as something" (or in the deserialize case render it 
from something) where deepCopy is rendering to another tree and 
serialize/deserialize is rendering to/from a bit stream. Not joining 
these seems wastefull. I've got a lib that has the "easy 80%" of the 
serialize/deserialize done that I'd donate if anyone cares.


More information about the dmd-concurrency mailing list