[webkit-help] WebKit2 Thread Safety

[Benjamin Poulain]

Hi Sami,

On 4/2/14, 8:12 AM, Sami Wagiaalla wrote:
> I have written a WebKitExtension to handle custom JavaScript injection 
> 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 
are very hard to debug (for example, you could re-enter JavaScript and 
cause undefined behavior in the page state).

Using threads to re-enter the core is not a solution. WebCore is not 
thread safe, and only specific subsystems of JavaScriptCore are thread 
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.

Benjamin