[webkit-dev] WTF::callOnMainThread() and re-entrancy

[Dmitry Titov]

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 <atwilson at 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 <dimich at chromium.org> wrote:
>
>> On Mon, Mar 8, 2010 at 11:38 AM, Alexey Proskuryakov <ap at 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 at lists.webkit.org
>>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20100308/68d32468/attachment.html>