Re: avoiding races in IPDL protocols

On Jul 15, 2009, at 2:16 AM, Jason Duell wrote:

> 1) Make the programmer anticipate race conditions, and allow (and
> handle) BarMsg when in state FOO.

I agree wholeheartedly with Benjamin - this is the wrong way to go  
about things.

> 2)  make states unidirectional (only send or recv).  If any particular
> state (including START) can only support messages in one direction,
> than we avoid races by making the conditions for them impossible.

I don't see any particular problem with this, but...

> 3) Possibly loosen #2 to allow states with bidirectional traffic, but
> only if states that follow them can handle all possible race condition
> messages that might occur (the IPDL compiler should be able to figure
> these out).

...I'd prefer the flexibility of being able to say "In this state,  
these messages can go back and forth willy-nilly, and I'm OK with that."

Starting with unidirectional states and waiting to see if we need  
bidirectional traffic for implementing a given protocol is what I'd  
advocate.

 > a BAR takes one down a bar-barous path.

booooooooo