Re: avoiding races in IPDL protocols

On 7/15/09 2:16 AM, Jason Duell wrote:

> 1) Make the programmer anticipate race conditions, and allow (and
> handle) BarMsg when in state FOO.  This might, alas, requires a lot of
> subtle thinking to get right (when we were hoping IPDL would make
> safely writing protocols fairly trivial).

Yeah, that defeats the point of having a protocol state system.

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

Certainly some of our protocols (I'm thinking of NPObject) will need to
support bidirectional traffic, but they may not need to do it with
asynchronous messages, only rpc-style messages.

If state transitions take place when a sync/rpc message is "finished" I
don't think the race condition applies, right?

In any case I think IPDL ought to statically verify that there are no
illegal race conditions between async messages, like #3.

> reliable, in-order, and low latency, so we avoid a *lot* of complexity
> there.

Technically our network is low-latency from the child to the parent but may
be high-latency from the parent to the child (the child may have long
processing loops or hang), but I don't think that makes a difference in the
argument!

--BDS