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
Another alternative is for us to add a flag to
scheduleDispatchFunctionsOnMainThread() which is passed as true in the case
where we are calling it from dispatchFunctionsOnMainThread():
// If we are running accumulated functions for too long so UI may
become unresponsive, we need to
On 09.03.2010, at 9:45, Drew Wilson wrote:
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 would help to have a more detailed description of the problem.
On Tue, Mar 9, 2010 at 11:13 AM, Alexey Proskuryakov a...@webkit.org wrote:
On 09.03.2010, at 9:45, Drew Wilson wrote:
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
On Tue, Mar 9, 2010 at 11:13 AM, Alexey Proskuryakov a...@webkit.org wrote:
On 09.03.2010, at 9:45, Drew Wilson wrote:
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
On 09.03.2010, at 11:23, Michael Nordman wrote:
1) We feel the need to change how Document::postTask() behaves,
because otherwise, the patch for https://bugs.webkit.org/show_bug.cgi?id=34726
doesn't work. We feel the need because it makes little sense for
it to have drastically different
On Tue, Mar 9, 2010 at 11:34 AM, Dmitry Titov dim...@chromium.org wrote:
On Tue, Mar 9, 2010 at 11:13 AM, Alexey Proskuryakov a...@webkit.orgwrote:
On 09.03.2010, at 9:45, Drew Wilson wrote:
Yeah, it's a race condition - it seems to all depend on whether the
worker resource gets loaded
On 09.03.2010, at 11:51, Drew Wilson wrote:
That actually is an interesting idea - perhaps we could implement
scheduleDispatchFunctionsFromMainThread() using a 0-delay timer in
the case where it's called from the main thread...
As an unsubstantiated idea, we could also consider using a
That's a great idea:
http://developer.apple.com/Mac/library/documentation/CoreFoundation/Reference/CFRunLoopObserverRef/Reference/reference.html#//apple_ref/c/tdef/CFRunLoopActivity
I've tried to post a timer if the scheduleDispatchFunctionsFromMainThread
comes on main thread - this fixes the test and it is a minimal change.
Drew, let me know if you want to dig deeper in CFRunLoopObserver, otherwise
I could whip up a patch (post a timer from main thread + postTask change
Yeah, that seems to be the least invasive.
And we're already confident that creating a zero-delay timer won't cause
event source starvation, since that's how postTask() used to work.
-atw
On Tue, Mar 9, 2010 at 12:53 PM, Dmitry Titov dim...@chromium.org wrote:
I've tried to post a timer if
On 09.03.2010, at 12:37, Drew Wilson wrote:
This gives us lots of places to hook.
scheduleDispatchFunctionsFromMainThread() could be a no-op on the
mac, if we just always invoke dispatchFunctionsFromMainThread() at a
specified point in the loop (e.g. kCFRunLoopBeforeWaiting).
Something
I saw a very similar bug recently regarding modal dialogs and focus/blur
events: https://bugs.webkit.org/show_bug.cgi?id=33962. I think you will see
the crash from that stacktrace with or without r55593 in place. For
example, currently some mouse event handlers can fire underneath a
window.alert
This is not surprising to me at all. The problem is even more complicated
when you consider window.showModalDialog.
I recently changed Chromium to suppress WebKit's shared timer during calls
to alert, confirm, prompt, and the beforeunload prompt. That may be why you
aren't seeing the problem
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
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
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
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
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
19 matches
Mail list logo
