Re: Simultaneous destructors

> > There's also something gross about how much the needs of IPDL
> > itself are getting inserted into the state protocols.
>
> Why do you say that?  These are all design decisions, IPDL doesn't
> "need" anything, it's malleable.

All I was saying is that right now IPDL imposes a certain burden on
the developer because of the 1) need to avoid sending more than one
message at a time in the same direction (for flow control and/or the
state mismatch issue), and 2) the need to do subtle two-phase
destruction.  But that's probably an acceptable cost in order to get a
provably race-free protocol, which is a very nice thing to have.  So
I'm still with the program, and hope I'm not sounding too grumpy :)

> > One thing that might help a little, if we do go down this road, is
> > the ability to have IPDL discard msgs in certain states.  For
> > instance: ...  Right now I'd have to make sure my onDataAvailable
> > method kept some state variable (essentially duplicating IPDL's),
> > so that I know to simply discard a packet if I'm in the CANCELLED
> > state.
>
> No, you don't.  You would use your IPDL actor's state to decide what
> to do....  Writing the IPDL protocol is the hard work.  Once the
> protocol is written, the above pseudocode can be easily written by
> just looking at the IPDL protocol (that's what I did).

Fair enough.  We may not need to both with DISCARD or |ghost| or
whatever, then.

> What the |ghost| specifier would mean is that *if* the message is
> sent/received from/in a state that allows it, then it's processed
> normally.  If it's sent/received from/in a state that *doesn't*
> allow it, then it's dropped.  

If we do go down this route, it seems like it would be much safer to
require the author to specify exactly which states would throw away
msgs, rather than adding a blanket "throw this away if I don't account
for it" attribute.  (I.e., I still like my DISCARD proposal better).

> Explicitly acknowledging channel messages seems like a high burden
> on total throughput.

This is a potential issue.  In the case of a small HTTP reply, for
instance, the parent necko will get it all in one socket read(), and
thus would essentially call OnStartRequest, OnDataAvailable, and
onStopRequest in succession.  Requiring an IPDL reply for each of
these would introduce two IPC round-trip latencies to the process.
I'm not sure how much that would show up in the overall reponsiveness
of the browser, but the sequence itself would possibly be orders of
magnitude more expensive, time-wise.

> This to me looks like another reasonable proposal for making it
> easier to write race-free destructors (i.e. by loosening IPDL's
> race-free-protocol rules).  I need to think more carefully about the
> implications of modifying the particular check that makes this
> protocol fail the race detector, though.

Given the potential throughput issue, this might be worth looking into
(it's also both an interesting research question, and a potential way
of making writing protocols more natural).  But it doesn't look like
we necessarily need it to get started.

Jason