Re: Cost of constructing a communication path vs. sending a message

On Thu, 16 Sep 2010 22:41:11 -0700, Chris Jones wrote:

Thank you for your answer Chris - I'm learning from it :)

> On 09/16/2010 04:03 AM, Mike Kristoffersen wrote:
>> Looking at the code it seems like constructing a protocol is much more
>> expensive than just sending a message - so in a case like this where we
>> have two objects communicating over time, is it then the best choice to
>> create the connection between them once, and use this connection to
>> communicate over time - or is it really better to (re-)create the
>> connection each time it is needed? - Is there a significant cost to
>> having a connection open all the time?
> 
> There's not a general answer to that question. it depends on the
> problem.  I don't know exactly what problem you're solving here, but the
> "request protocol" pattern with Constructor/__delete__ encapsulating the
> request might be what you want.  Depending on what start/stop really
> mean, tracking nested and overlapping requests can become tricky, and
> you'd likely end up duplicating the actor-management logic.

Start means "Start sending me geolocation positions", Stop means "Stop 
sending me geolocation positions" - they can't be nested, nor 
overlapping.  

They are always send between the same objects (the objects are never 
deleted after they are initially created (*), they are part of a service 
and there is never more than one instance in each process)

> 
> Creating/destroying an actor is cheap, essentially |new
> FooActor()/delete actor|| and a hash table insert/delete on both sides.
>   Sending a message with IPC is much much more expensive than
> constructing/registering/unregistering/deleting an actor.

I could be misunderstanding what you are saying, but what I'm hearing is 
that you say it is cheaper to transmit information between the child 
process and the parent process by doing a "SendPGeolocationConstructor()" 
than sending a message like "SendStart()" on an existing connection - if 
I didn't misunderstand this, and we strive to use the cheapest solution, 
why do we have the messages then, is it only to ensure communication 
between specific end points?  (only talking about the async case here)

If I may extend the question a bit - as a response to the start request 
from the child process, the parent process will start to send geolocation 
events to the child process - should I create a separate protocol for 
this and then call the constructor in it to transmit the position, or 
keep it as the message on the protocol that is setup when the child needs 
to get geolocations?

^__^
Mike

(*) The objects are deleted as part of the shutdown of the browser, but 
as far as this discussion goes, they can be seen as always being there.