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

[Drew Wilson]

Following up with a related note - does anyone have any insight into how the
Cocoa event loop dispatches events from different sources? In particular, I
have a test (worker-cloneport.html) which posts a port back and forth
between two endpoints (both on the main thread).

With the change to Document.postTask() I described earlier in this thread,
this test results in there always being a pending event (posted via
performSelectorOnMainThread) when we re-enter the cocoa runloop. It appears
that the run loop *always* dispatches this event before dispatching events
from NSURLConnection - the result is that any pending resource loads never
complete.

Is there some kind of prioritization within the cocoa run loop so that
certain types of events (like NSURLConnection events) if there are no
pending events of other types?

-atw

On Mon, Mar 8, 2010 at 2:08 PM, Dmitry Titov <dimich at chromium.org> wrote:

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