Bug 1751948 - Part 5: Ensure we don't release ActorLifecycleProxy while holding MessageChannel's Monitor, r=jld
Releasing ActorLifecycleProxy can lead to the IToplevelProtocol being destroyed, due to the reference being the last reference. If this happens, we can deadlock due to the MessageChannel embedded in IToplevelProtocol locking mMonitor during its' destructor. This patch moves acquiring the proxy earlier in the method, so that we do not deadlock in this case any longer. Differential Revision: https://phabricator.services.mozilla.com/D137169
This commit is contained in:
@@ -367,13 +367,14 @@ class MessageChannel : HasResultCodes {
|
||||
|
||||
bool HasPendingEvents();
|
||||
|
||||
void ProcessPendingRequests(AutoEnterTransaction& aTransaction);
|
||||
bool ProcessPendingRequest(Message&& aUrgent);
|
||||
void ProcessPendingRequests(ActorLifecycleProxy* aProxy,
|
||||
AutoEnterTransaction& aTransaction);
|
||||
bool ProcessPendingRequest(ActorLifecycleProxy* aProxy, Message&& aUrgent);
|
||||
|
||||
void EnqueuePendingMessages();
|
||||
|
||||
// Dispatches an incoming message to its appropriate handler.
|
||||
void DispatchMessage(Message&& aMsg);
|
||||
void DispatchMessage(ActorLifecycleProxy* aProxy, Message&& aMsg);
|
||||
|
||||
// DispatchMessage will route to one of these functions depending on the
|
||||
// protocol type of the message.
|
||||
@@ -516,7 +517,7 @@ class MessageChannel : HasResultCodes {
|
||||
};
|
||||
|
||||
bool ShouldRunMessage(const Message& aMsg);
|
||||
void RunMessage(MessageTask& aTask);
|
||||
void RunMessage(ActorLifecycleProxy* aProxy, MessageTask& aTask);
|
||||
|
||||
typedef LinkedList<RefPtr<MessageTask>> MessageQueue;
|
||||
typedef std::map<size_t, UniquePtr<UntypedCallbackHolder>> CallbackMap;
|
||||
|
||||
Reference in New Issue
Block a user