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

Drew Wilson atwilson at google.com
Mon Mar 8 13:45:39 PST 2010


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/ba5ff456/attachment.html>


More information about the webkit-dev mailing list