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

[Michael Nordman]

On Tue, Mar 9, 2010 at 11:13 AM, Alexey Proskuryakov <ap at 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 machine.
>>
>
> It would help to have a more detailed description of the problem. I've been
> following the discussion in bugs and in this thread, but I'm still unsure
> about some aspects of it.
>
> Seems that there are two issues at hand:
>
> 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 behavior depending on what thread it's called from.
>
> It feels like a good change to make indeed, but I'm surprised that it
> apparently went through review unmentioned and unquestioned. The questions
> to ask are why exactly it was needed, and whether there are other ways to
> fix bug 34726.
>

This was discussed somewhat off list between dumi, dimich, and myself (and
whomever else dumi traded notes with). We were very surprised that tasks
scheduled via postTask() were not executed in the same order as being
scheduled. This change to postTask() was a shot at remedying that... but low
and behold, something was apparently depending on the out of order
execution?


>
> 2) if we make that change, the worker-cloneport.html test starts to fail.
>
> I didn't attempt to debug this myself, and I don't quite understand the
> problem description. I see only one postMessage loop in the test, and it's
> in worker code. How can it be executed before the worker resource gets
> loaded?
>
>
>  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?
>>
>
> These main thread calls do not use events for processing. CF/NSRunLoop has
> a concept of run loop sources, which can generate events or perform other
> actions, see <
> http://developer.apple.com/mac/library/documentation/CoreFoundation/Reference/CFRunLoopRef/Reference/reference.html>
> and <
> http://developer.apple.com/Mac/library/documentation/CoreFoundation/Reference/CFRunLoopSourceRef/Reference/reference.html
> >.
>
>
> - 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/20100309/84fe2902/attachment.html>