fix: use serial queues and revert string copy changes #156
Conversation
rigor789
changed the title
| dispatch_sync(this->messageLoopQueue_, ^{ | ||
| loopsRunning = runningNestedLoops_; | ||
| terminated_ = false; | ||
| if (runningNestedLoops_) { | ||
| return; | ||
| } | ||
| this->runningNestedLoops_ = true; | ||
| }); |
There was a problem hiding this comment.
Hey @edusperoni, curious what issue/scenario led to the introduction of these additional dispatch_sync wrappers in runMessageLoopOnPause and quitMessageLoopOnPause. I identified the culprit messageLoopQueue_ after a while today trying to work out why my app would crash every time I triggered a breakpoint or debugger statement in my code by executing the containing function from devtools console.
When we have a debugger statement or breakpoint set somewhere in our code, say in a function defined in global scope, and we trigger this by evaluating an expression in DevTools console e.g. calling the function, this now creates a deadlock. When the debugger statement gets hit in the same synchronous execution initiated by this->dispatchMessage(message) in onFrontendMessageReceived, we end up in runMessageLoopOnPause, which now schedules its block to check for runningNestedLoops_ into messageLoopQueue_ - but that queue is currently waiting for the execution of runMessageLoopOnPause to finish.
My idea was that there should be a separate queue for execution/dispatch of messages from the one(s) in which blocks pump new messages, which blocks would be added to via dispatch_async, but I hit various issues trying to implement it that way e.g. dispatch_semaphore_wait never returning. I have ended up just commenting all the dispatch_sync(this->messageLoopQueue_ wrappers which seems to have fixed the crash I was having issues with.
No description provided.