Re: Simultaneous destructors

> state CANCELLED:
>    discard dataavailable;
>    send datadone goto DEAD;

That's fine.  I'd prefer to not lose the "recv", so it would look
like

    recv discard dataavailable;

But I don't care very much.

> >> 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.
>
> OnStart/OnStop haven't entered into the discussion so far, so I'd
> tentatively claim that you're arguing against a strawman.  How do they
> fit into the protocols that have been tossed around so far?

Once an HTTP channel is opened by the child process, the chrome HTTP
channel that gets created will go through the regular steps of getting
data from the network, and calling OnStartRequest/OnDataAvailable/
OnStopRequest.  These functions (and the data/headers) need to be made
available in the child process.  Right now my plan is to simply proxy
each OnStart/OnData/OnStop function to the child via an IPDL message
(it may be possible to glob them together into one message which is
sent to the child, but that may not be trivial, given that there may
be chains of listeners/observers that need to be called in the correct
order).

So we're looking at 3 IPC messages in a row, for a small HTTP reply
that comes in with one socket read().  One possibility is that we can
send them all in a row:

    PARENT           CHILD
    -------------------------
    OnStart  --->
    OnData    --->
    OnStop     --->

We still have the overhead of 3 IPC messages, but they can be "in
flight" at the same time.

But under your proposed rule that one side can't send multiple
messages in a row in IPDL, we have to add acknowledgements to each
message:

    PARENT     CHILD    PARENT    CHILD   PARENT    CHILD
    -----------------------------------------------------
    OnStart -->
               moar -->
                        OnData -->
                                  moar -->
                                          OnStop -->

(I hope the ASCII art is comprehensible).  Here we're adding two round-
trip IPC times, because each message needs to be ACK'd before we can
send the next one.  This certainly adds extra latency, and might
affect overall bandwidth as well (for larger replies with many
onDataAvailable calls), depending on the overheads involved.


> And you're worried about the IPC/IPDL overhead being "more expensive"
> than what?  The current case where OnStart/OnData/OnStop are processed
> as Runnable events in a single event loop?

Yes.  Obviously we're going be to more expensive (3 IPC calls can't be
free), but there's a potentially big difference between issuing them
in a row versus waiting for an ACK between each.

> I don't think there'll be throughput issues with double-buffering, but I
> agree that we don't need to solve this to get started.

I agree that double-buffering doesn't inherently cause a throughput
issue here.

Jason