Re: Simultaneous destructors

OK, Chris, you've convinced me that the extra 'moar' messages (and
round-trip
latency) is only needed when multiple OnDataAvailable events need to
happen.
And it seems likely as you suggest that these latencies are not likely
to be
noticeable given that parsing, etc. will be underway.

So performance doesn't seem to be a big consideration here, at least
for the
necko case.  I still have usability concerns.

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

Um, that /is/ the additional complexity :)   Yes, it sounds like
nothing much in
theory, but it's certainly going to be more work, and might be subtle
(we
currently report to listeners when OnDataAvailable is fired:  would we
consolidate the notifications, too?  Firebug might get less accurate
info about
network activity this way, for instance).

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

I understand that this is a concern in theory, but am wondering how
likely it is
in practice.  What's the "permanent" divergence here, and why is it so
bad if we
still detect/handle all transitions correctly?  If we're talking about
a
trade-off between the protocol being a bit more subtle (but still
provably
correct), versus a "simpler" protocol (only in the sense that
divergence isn't
possible:  but I still need to add application-orthogonal messages
like "moar"
to make it correct, i.e. it's not unambugiously "simpler" IMHO) that
makes me do more
work do accomodate IPDL, I'd much rather choose the first.

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

A nit:  my "discard" proposal was just to explicitly drop messages
when it's
known that they aren't needed (i.e. an OnDataAvailable arriving after
the child
has already Cancel'ed the the channel).  I'm not sure what you mean by
"causing
bad state transitions", as the example given doesn't transition state
(we start
CLOSED and stay CLOSED).

Jason