[webkit-help] WebKit2 Thread Safety
benjamin at webkit.org
Wed Apr 2 11:32:23 PDT 2014
On 4/2/14, 8:12 AM, Sami Wagiaalla wrote:
> for the Eclipse SWT Browser, but I have run into the following
> deadlock scenario while running the test suite:
> A new WebView is created in the UI process this requires some handling
> in the Web process which eventually sends a synchronous message to the
> UI process and blocks to wait for the reply. The message results in a
> "create" signal in the WebView which in Eclipse code is forwarded to
> observers. Now if an observer tries to do anything which results in an
> attempt to inject custom JS this is forwarded to the WebExtension
> which is blocked because the Web Process is blocked since the signal
> handler has not yet returned.
> My questions are has anyone else run into this problem ? And if I were
> to create a thread in the extension to handle messages from the UI
> process would it be safe to call core API from a second thread.
> Specifically JS* functions.
I have not run into this particular problem but we ran into many
problems with synchronous IPC over the years. A deadlock is a lucky
outcome in your situation, usually it causes undefined behaviors that
cause undefined behavior in the page state).
Using threads to re-enter the core is not a solution. WebCore is not
safe. If you re-enter arbitrary web pages, you will run into additional
problems since scripts are not written to be re-entrant.
The solution is almost always to redesign the interprocess IPC to use
asynchronous messages. In this case, you may want to break the
synchronicity from the WebProcess to the UIProcess, or execute the
custom JS asynchronously.
More information about the webkit-help