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
_______________________________________________
webkit-help mailing list
webkit-help@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-help
