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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]>wrote: >>> >>>> On Mon, Mar 8, 2010 at 11:38 AM, Alexey Proskuryakov >>>> <[email protected]>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 >>>>> [email protected] >>>>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev >>>>> >>>> >>>> >>> >> >
_______________________________________________ webkit-dev mailing list [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
