Re: Simultaneous destructors

Benjamin Smedberg wrote:
> 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.
> 

I'd prefer not to make this change until we have a dire need.  I think 
it will make protocols harder to reason about, and I like the 
|unchecked| and |discard| proposals better than this.

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

I disagree, if you're referring to the double-buffering scheme I was 
referring to earlier.

Cheers,
Chris