Re: Simultaneous destructors

Jason Duell wrote:
>> 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).
> 

I don't like DISCARD because it refers to other states, not the 
state/trigger at which it's written.

I'm fine with either

  (1) |unchecked| specifier for messages as described earlier, only 
allowed if the messages meet the conditions
      (a) async
      (b) never cause state changes (i.e. always self-loop); e.g. the 
dataavailable message we've been discussing

or

  (2) Modification of |discard|: place it at the state where the message 
should be discarded.  So the Channel protocol could be something like

state NORMAL:
   send dataavailable goto NORMAL;
   send datadone goto DONE;
   recv cancel goto CANCELLED;

state DONE:
   recv cancel goto DEAD;

state CANCELLED:
   discard dataavailable;
   send datadone goto DEAD;

state DEAD:
   recv delete;

(Or thereabouts, I didn't verify this protocol.)

The caveat is that you wouldn't be able to |discard| in the 
"__deleted__" state, so the shutdown sequence would still need to be 
race-free except where |discard dataavailable| was concerned.

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

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?

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

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.

Cheers,
Chris