Re: avoiding races in IPDL protocols

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

I don't think so.  If you're allowing rpc msgs in either direction
that have different state changes (i.e. one transitions to FOO, one to
BAR--just as in my earlier example), you can still get overlapping rpc
requests, and the same race condition applies.   The difference is
that if you're waiting for a reply to your FooRpc and you recv a
BarRpc request, you will be woken up, and could handle recovery
(assuming you've anticipated it:  this is really a subcase of my case
#1).   If you're using "sync" methods, by contrast, I assume you'll
simply deadlock (or the system will kill the child when it detects
deadlock:  cjones, correct me if I'm wrong).

If the rpc msgs don't cause state transitions, than we'd be ok.

I'm going to send an email to some of the Singularity folks to ask how
they've dealt with this issue.

Jason