Bug 127370 - [WK2][iOS] callOnMainThread() from main thread sometimes results in ASSERTs.
Summary: [WK2][iOS] callOnMainThread() from main thread sometimes results in ASSERTs.
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: New Bugs (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Jer Noble
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-01-21 14:43 PST by Jer Noble
Modified: 2014-01-27 13:12 PST (History)
7 users (show)

See Also:


Attachments
Patch (1.70 KB, patch)
2014-01-21 14:51 PST, Jer Noble
no flags Details | Formatted Diff | Diff
Patch (9.38 KB, patch)
2014-01-21 16:49 PST, Jer Noble
no flags Details | Formatted Diff | Diff
potential patch (1.55 KB, patch)
2014-01-23 12:13 PST, Pratik Solanki
no flags Details | Formatted Diff | Diff
Patch (2.80 KB, patch)
2014-01-23 16:55 PST, Pratik Solanki
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Jer Noble 2014-01-21 14:43:21 PST
[WK2] callOnMainThread() from main thread sometimes results in ASSERTs.
Comment 1 Jer Noble 2014-01-21 14:51:15 PST
Created attachment 221791 [details]
Patch
Comment 2 Jer Noble 2014-01-21 14:54:53 PST
Too many commas in the ChangeLog. Will fix.
Comment 3 Jer Noble 2014-01-21 16:26:11 PST
Comment on attachment 221791 [details]
Patch

ap, after talking to JoePeck about this patch on IRC, I think the new direction is to add a less ambiguous "callOnWebThread()" method.
Comment 4 Jer Noble 2014-01-21 16:49:30 PST
Created attachment 221808 [details]
Patch
Comment 5 WebKit Commit Bot 2014-01-21 16:50:23 PST
Attachment 221808 [details] did not pass style-queue:


ERROR: Source/WTF/wtf/MainThread.h:61:  Extra space before ( in function call  [whitespace/parens] [4]
ERROR: Source/WTF/wtf/MainThread.h:69:  Extra space before ( in function call  [whitespace/parens] [4]
Total errors found: 2 in 6 files


If any of these errors are false positives, please file a bug against check-webkit-style.
Comment 6 Alexey Proskuryakov 2014-01-21 23:22:20 PST
Comment on attachment 221808 [details]
Patch

The new patch crashes right and left on EWS, see <http://webkit-queues.appspot.com/results/5607835786280960>. Crashes are flaky, so EWS can't decide what to report.
Comment 7 Jer Noble 2014-01-22 11:10:27 PST
It looks like the behavior of WebThreadRun() is subtly different than callOnMainThread().  Specifically, if WebThreadRun() is called from the web thread, the task is run synchronously.  In callOnMainThread(), if the current thread is the main (or web) thread, the task is run in the next run-loop.
Comment 8 Pratik Solanki 2014-01-23 12:00:12 PST
I think we should make sure that callOnMainThread always calls on the WebThread for iOS. The fact that it dispatched on the main (UI) thread sometimes is a bug.
Comment 9 Pratik Solanki 2014-01-23 12:13:40 PST
Created attachment 222013 [details]
potential patch

Something like this may do the trick. Needs testing though.
Comment 10 Joseph Pecoraro 2014-01-23 16:27:45 PST
Comment on attachment 222013 [details]
potential patch

View in context: https://bugs.webkit.org/attachment.cgi?id=222013&action=review

> Source/WTF/wtf/mac/MainThreadMac.mm:80
>      mainThreadEstablishedAsPthreadMain = false;
>      mainThreadPthread = pthread_self();
>      mainThreadNSThread = [[NSThread currentThread] retain];
> +    mainThreadRunLoop = CFRunLoopGetCurrent();

This is inside of !USE(WEB_THREAD). I think you will want to always initialize this variable, regardless of USE(WEB_THREAD) or not.

Which means, on iOS which has USE(WEB_THREAD), mainThreadRunLoop in the UIProcess, NetworkProcess, and WebProcess will be uninitialized until initializeWebThreadPlatform is called. On the WebProcess, that is probably pretty early on. In the UIProcess / NetworkProcess I don't know if that is ever called. I suspect it may not be called at all. In that case, having an uninitialized mainThreadRunLoop and calling callOnMainThread would trigger CFRunLoopAddTimer(NULL, ...).

There are UIProcess/NetworkProcess calls to "callOnMainThread":

    shell> cd Source/WebKit2; ack callOnMainThread
    NetworkProcess/NetworkResourceLoadScheduler.cpp
    170:        callOnMainThread(NetworkResourceLoadScheduler::removeScheduledLoaders, this);

    UIProcess/API/mac/WKPrintingView.mm
    400:        callOnMainThread(prepareDataForPrintingOnSecondaryThread, self);

Next, on iOS, we would want to verify that those NetworkProcess/UIProcess calls would be okay to happen on either the MainThread or WebThread. Since the "mainThreadRunLoop" could spontaneous change from MainThread to WebThread in the UIProcess if the UIProcess lazily initializes a WebThread (e.g. makes a WebKit1 WebView).
Comment 11 Pratik Solanki 2014-01-23 16:55:32 PST
Created attachment 222043 [details]
Patch
Comment 12 Joseph Pecoraro 2014-01-23 17:01:20 PST
Comment on attachment 222043 [details]
Patch

This looks good to me. Does Benjamin Poulain or another person more familiar with the WebKit2 wanna check this as well?
Comment 13 Pratik Solanki 2014-01-23 19:08:48 PST
Comment on attachment 222043 [details]
Patch

Withdrawing this patch. There's more subtlety here.
Comment 14 Pratik Solanki 2014-01-27 12:35:39 PST
Joe and I discussed this and we think the first patch <https://bug-127370-attachments.webkit.org/attachment.cgi?id=221791> that Jer had is the right approach. callOnMainThread() always scheduled work on the web thread on iOS. That changed recently when we made changes to the definition of isMainThread() as part of upstreaming iOS code (r153950 made for bug 119644). We should use isWebThread() in this function. isWebThread() is defined to be the main thread on non-iOS code. And will do the right thing on iOS.
Comment 15 Jer Noble 2014-01-27 12:38:10 PST
Comment on attachment 221791 [details]
Patch

Un-obsoleting attachment #221791 [details].
Comment 16 WebKit Commit Bot 2014-01-27 13:12:15 PST
Comment on attachment 221791 [details]
Patch

Clearing flags on attachment: 221791

Committed r162862: <http://trac.webkit.org/changeset/162862>
Comment 17 WebKit Commit Bot 2014-01-27 13:12:19 PST
All reviewed patches have been landed.  Closing bug.