Re: Simultaneous rpc calls

Benjamin Smedberg wrote:
> What happens when both sides of a connection send a simultaneous rpc call, e.g.:
> 
> Parent:                Child:
> NPP_DestroyStream      NPN_DestroyStream
> 
> Part 1:
> How are the messages interleaved? Does this deadlock, or does the native
> stack wind through both messages?
> 
> Parent stack:          Child stack:
> 0) NPN_DestroyStream   0) NPP_DestroyStream
> 1) IPC Code            1) IPC Code
> 2) NPP_DestroyStream   2) NPP_DestroyStream
> 3) Pluginhost code     3) Plugin code
> 

RPC can never deadlock.  The above will happen; whether it makes sense 
is a different question...

That said ...

> Assuming it doesn't deadlock (since that would be bad!), I'm going to need
> some way of gracefully dealing with this race: neither side has committed a
> programming error.
> 

I don't see how this race can occur in NPStream.  The browser owns the 
"thread of control" and plugin code can only execute when the browser 
transfers control to the plugin (through a function call in 
single-process land, RPC message in multi-process).  Your race above 
would only happen if the plugin tried to send NPN_DestroyStream() of its 
own volition, which NPAPI doesn't allow.

> Part 2:
> 
> Both of these calls map to the ~NPBrowserStream destructor. Will this
> invalidate the actor handle as the message is sent? Since I don't think the
> client code can prevent the race condition, the IPC/IPDL code will at least
> need to gracefully handle the destructor being called simultaneously from
> both sides.
> 

(Deferring until I know how the race can happen.)

Cheers,
Chris