Chromium Code Reviews| Index: ppapi/proxy/host_dispatcher.cc |
| =================================================================== |
| --- ppapi/proxy/host_dispatcher.cc (revision 77054) |
| +++ ppapi/proxy/host_dispatcher.cc (working copy) |
| @@ -73,6 +73,23 @@ |
| return false; |
| } |
| +bool HostDispatcher::Send(IPC::Message* msg) { |
| + // Clear the unblock flag for all messages from the host to the plugin. |
| + // |
| + // This prevents reentrancy in the plugin when both sides send sync messages. |
| + // Since the plugin dispatcher does NOT do this, we won't get a deadlock, |
| + // but can get reentrancy in the host. |
| + // |
| + // This is a temporary workaround until all plugin messages can be made |
| + // non-blocking (which is a much better solution). It's preferrable to the |
| + // alternatives because in general plugin -> host sync messages interact with |
| + // the pepper implementation which is reasonably reentrant. On the other |
|
piman
2011/03/07 21:01:29
Well, technically the browser side needs to be ree
|
| + // hand, the plugin will not expect an input event from inside a call to |
| + // CreateResource. |
| + msg->set_unblock(false); |
|
piman
2011/03/07 21:01:29
So, this is in general ok, and what we want, but t
|
| + return Dispatcher::Send(msg); |
| +} |
| + |
| bool HostDispatcher::OnMessageReceived(const IPC::Message& msg) { |
| // Handle common control messages. |
| if (Dispatcher::OnMessageReceived(msg)) |