[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