On Mon, Aug 17, 2009 at 2:43 PM, bsmedberg<[email protected]> wrote: > The most obvious problem is that both processes may send a synchronous > IPC message at the same time. Assuming that these don't deadlock, the > native stack for the two calls would end up interleaved.
While there may be a possibility for deadlock (I haven't looked--jam will know more), the native stack on the plugin process side should not get interleaved (at least using the Chromium IPC mechanism. In particular, the plugin process will not process incoming IPC requests while a synchronous IPC call is outstanding. So in the case you've described, if the plugin has called NPN_DestroyStream, it will not even see the NPP_DestroyStream until NPN_DestroyStream has completed. At that point, the plugin host process may be able to determine that the stream has already been destroyed, and not even forward the call to the plugin itself. In addition, a number of operations which are normally synchronous in in-process NPAPI are asynchronous in Chromium (painting, for example). This does add complexity, but it helps avoid deadlock and improve performance. --Amanda -- "Portability is generally the result of advance planning rather than trench warfare involving #ifdef" -- Henry Spencer (1992) --~--~---------~--~----~------------~-------~--~----~ Chromium Developers mailing list: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
