Re: Simultaneous destructors

Benjamin Smedberg wrote:
> On 10/12/09 7:40 PM, Chris Jones wrote:
> 
>> I'd prefer not to make this change until we have a dire need.  I think
>> it will make protocols harder to reason about, and I like the
>> |unchecked| and |discard| proposals better than this.
> 
> Explicitly acknowledging messages has additional costs beyond just the IPC
> latency and ping-pong times. Most importantly is that we currently have
> programming models where we don't have to wait to fire multiple
> onDataAvailable events. Since we can't completely change necko, the channel
> parent class will have to accept "immediate" calls to
> onDataAvailable/onStopRequest and create a queue for them. This is a fair
> bit of complexity in the channel classes that we could avoid.
> 

I'm not sure about this added complexity.  Can't it be avoided by having 
Necko "queue" OnDataAvailable events by appending the data to an 
out-buffer?  This would hide the IPC impl from Necko producers in the 
parent process and consumers in the child process.

I think in the long run we might want something like this anyway, to 
avoid spamming the content process with a lot of smallish buffers.  But 
I would agree that this a latency/throughput trade-off that might be 
hard to get right.  It seems worthwhile for us to make a simple 
mathematical model of network latency and throughput in Mozilla.  Do we 
have something like this already?

> In addition, every time you require a ping pong you're not just dealing with
> the IPC latency: you're also dealing with the latency of the event loop in
> both processes.
> 

Sure, but double buffering (in common cases) will automatically adjust 
itself so that IPC/event-loop latency isn't a bottleneck.

> It seems to me that we'd be better off putting more work into IPDL to allow
> parent and child to do out-of-sync state transitions. We can prove that the
> possible set of transitions is still theoretically sound, and at the same
> time reduce the burden on protocol implementers.
> 

We could certainly do this, IPDL has all the information it needs.  The 
problem is that this could allow actor state to diverge permanently, 
which I think would make protocols harder to understand.

If we end needing to add this kind of feature (it's still not clear to 
me that we need it), then IMHO, jduell's |discard| proposal is the best 
solution to the problem --- we keep the simplicity of "entangled" state, 
and the programmer has to explicitly acknowledge that he understands the 
race conditions and wants IPDL to drop the messages that would cause bad 
transitions.

Cheers,
Chris