[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