So the implication is that every single place that uses tasks has to have an associated activeDOMObject() or other hooks in ScriptExecutionContext so it can get suspend/resume calls and try to queue up the tasks for later? That seems a) hard (since not everything that uses tasks necessarily has an activeDOMObject), and b) fragile because we'll undoubtedly miss cases -- there's something like 70 calls to callOnMainThread()/postTask() in the WebCore code.
Is there no way to do something at a lower level? callOnMainThread() already keeps a queue of pending callbacks, so it seems like just not dispatching those callbacks might be better? It's tricky because you don't necessarily know which ScriptExecutionContext a task is destined for at that low level. -atw On Mon, Mar 8, 2010 at 1:24 PM, Dmitry Titov <[email protected]> wrote: > On Mon, Mar 8, 2010 at 11:38 AM, Alexey Proskuryakov <[email protected]>wrote: > >> >> On 08.03.2010, at 11:21, Drew Wilson wrote: >> >> So, my question is: does it surprise anyone that tasks posted via >>> callOnMainThread() are getting executed even though there's a modal dialog >>> shown? And is there anything I should be doing in my task handler to make >>> sure we aren't re-entering JS execution inappropriately in these cases? I'm >>> just concerned that the way we're posting tasks from worker threads to the >>> main thread may cause reentrancy problems. >>> >> >> It is not correct to deliver messages from worker threads when an alert or >> a modal window is displayed. It may be ok for modal dialogs that are >> triggered asynchronously (such as credentials dialog). >> >> We have a manual test regression for a related issue, >> WebCore/manual-tests/js-timers-beneath-modal-dialog.html. You can compare >> how timers work, and how worker messages are delivered to find out how to >> fix the problem. >> > > Timers are suspended by > ScriptExecutionContext::suspendActiveDOMObjects/resumeActiveDOMObjects from > PageGroupLoadDeferrer. So the context (Document) knows when it is suspended > and when it gets resumed. > It seems the task to process accumulated port messages can be postponed > until resume. > > > >> - WBR, Alexey Proskuryakov >> >> >> _______________________________________________ >> webkit-dev mailing list >> [email protected] >> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev >> > >
_______________________________________________ webkit-dev mailing list [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
