Yeah, it's a race condition - it seems to all depend on whether the worker resource gets loaded before the postMessage loop starts. Failure rate is around 30-50% on my machine.
It looks like events have priority in Cocoa, and I'm guessing that performSelectorOnMainThread() creates events with a higher priority than those generated by URLConnection, which can lead to starvation. I'm not certain what the right fix is, other than to maybe use a different method of dispatching events other than performSelectorOnMainThread that lets us set a lower priority? -atw On Mon, Mar 8, 2010 at 7:24 PM, Dmitry Titov <dim...@chromium.org> wrote: > At least user input is dispatched even if there are outstanding > performSelectorOnMainThread calls: > https://bugs.webkit.org/show_bug.cgi?id=23705 > > With the change in postTask, the cloneport test does not always hang - on > my machine it's 50-50. There is some racing condition somewhere perhaps... > > > On Mon, Mar 8, 2010 at 5:29 PM, Drew Wilson <atwil...@google.com> wrote: > >> 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 <dim...@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 <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
