Re: Simultaneous destructors

On 10/9/09 4:21 AM, Chris Jones wrote:

> Sorry, this isn't quite right.  The protocol is indeed racy per IPDL's
> rules, but the reason it's racy is that it allows the parent's and
> child's states to get out of sync for more than one "transition".  I
> don't see any cases in which a message would arrive in a state where
> it's not allowed.
> 
> 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.  The basic problem is that this protocol
> as written would allow the parent's and child's states to get out sync
> for an indefinite number of messages, which doesn't seem desirable in
> general.

Oh, I figured it wasn't a "race" until the states which were out of sync
actually caused disallowed messages... it seems to me that we want the
behavior that the two sides can have different states as long as all the
possible message states remain legal.

It does require that you compute not only the transitions from the current
state, but also the transitions from any future states which may be
asynchronously entered while the other side still thinks you're in a prior
state.

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

--BDS