[dmd-concurrency] draft 5

[Kevin Bealer]

On Tue, Jan 19, 2010 at 8:02 AM, Michel Fortin <michel.fortin at michelf.com>wrote:

>
> That's nice and appropriate for inter-thread communications.
>
> But won't it be a little wasteful when we come to inter-process or network
> communications, when you need to make a serialized copy of the message? If
> you force the user to make an immutable copy, and then create a new copy via
> serialization, the immutable copy is wasted, no?
>

> I ask now because this is a pretty fundamental thing (passing a message)
> and you said at the start of this mailing list that the intent was for the
> message API to scale well to all these cases.
>

I think the best thing is to have two methods overloaded (or with different
names if needed); one would pass an immutable object, the other a shared
object.

There is a kind of open question with passing a message -- if I give a
(mutable) shared message to you, is it still mine?  In other words, I could
pass a shared object into the messaging system, and then one of us could
modify the message.  This will work differently depending on whether the
other party is on the other side of a deep copy (e.g. network versus local).

Presumably the default approach is to write code that expects a deep copy
(serialize/deserialize), but works fine without it.  I can imagine some
cases where it would be useful to have this schism though.  For example, a
node of a document that contains a reference to a web or database hosted
resource.  The object could locally cache the resource if it happens to get
loaded, but if the object is sent over a network before this caching
happens, you'd be just as happy to have two separate copies and let each of
them lazy fetch the object if they need it.

Kevin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/dmd-concurrency/attachments/20100119/01133ea8/attachment.htm>