Re: Simultaneous destructors
Chris Jones <[email protected]>
| Newsgroups | gmane.comp.mozilla.devel.dom |
|---|---|
| Message-ID | <[email protected]> |
Benjamin Smedberg wrote: > On 11/9/09 6:36 PM, Chris Jones wrote: > >>> 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). >>> >> I can't really comment on this because know very little about Necko >> code. bsmedberg? > > It seems desirable to me that we do not require acknowledging every message: > when the channel has data available, it sends that data along and doesn't > cache it. > Hmm, OK. From my limited perspective of not knowing necko code, I still think that the burden of queueing DataAvailable() favors well against relaxing IPDL checks. But if we really want them to be immediately forwarded, we'll need either |discard| or divergent state, see below. > I slightly prefer the divergent-path approach rather than the discard > approach, for one main reason: it means that we don't have to implement > special handling for actors which have already been "destructed" but are > still receiving messages. > You mean for stateless protocols? We don't need this special handling for necko channels, the destruction sequence isn't racy with both explicit ACK and |discard|. > I don't think my opinion is strong enough to *insist* on the divergent-path > approach, though. If we do go with the discard-bad-messages approach, I'd > like a very solid approach torwards zombie actor IDs. > Divergent state doesn't help inherently racy protocols, because by definition those are stateless protocols. I haven't fully worked out the details of keep-alive for stateless protocols, but the basic idea would be to keep the actor alive on the side(s) sending __delete__ until the other side ACKs the delete, regardless of async/sync/RPC __delete__. (The ACK is the part I haven't fully worked out.) Cheers, Chris