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

On 09/17/2010 02:45 AM, Mike Kristoffersen wrote:
> On Thu, 16 Sep 2010 22:41:11 -0700, Chris Jones wrote:
>> 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)
>

If you're already tracking enough state in the service to ensure that 
start/stop don't overlap or nest, the request-actor pattern probably 
doesn't buy you anything here.  Start/Stop messages seem OK to me.

>>
>> 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)
>

No, you're misunderstanding ;).  I'm saying that the non-IPC parts of 
actor creation and destruction (new FooActor()/delete actor and hash 
table operations) are much much cheaper than sending a message with IPC. 
  The request-actor pattern can reduce extra IPC messages by having the 
the SendFooActorConstructor() message also mean "start request" and the 
Send__delete__() message also mean "stop request", instead of having 
extra (extraneous) StartRequest()/StopRequest() messages between 
SendCtor()/Send__delete__().

> 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?
>

See above; sounds like explicit Start/Stop on the service actor is good 
enough, since the content-process part of the service is apparently 
tracking a lot of state already.

Cheers,
Chris