Many tasks are just fine to execute while modal UI is present. For example, XHR in a Worker probably should not be frozen by an alert on the parent page. That posts tasks to main thread for loader. Also, it's unclear if a task can be simply delayed or in fact some other action should be performed at resume point - for example, timers re-calculate the next fire time.
Maybe there can be a generic mechanism for tasks to participate in suspend/resume... It'd require a better definition of the events - for example, is there a difference between "suspense on modal UI" and "suspense on going into BF cache"? Probably there is. Dmitrty On Mon, Mar 8, 2010 at 1:45 PM, Drew Wilson <atwil...@google.com> wrote: > 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 <dim...@chromium.org> wrote: > >> On Mon, Mar 8, 2010 at 11:38 AM, Alexey Proskuryakov <a...@webkit.org>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 >>> webkit-dev@lists.webkit.org >>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev >>> >> >> >
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
