[webkit-dev] inspector calls from XHR running in a (html5) worker

David Levin levin at google.com
Tue Dec 30 11:14:27 PST 2008


Problem
In XMLHttpRequest::didFinishLoading (WebCore/xml/XMLHttpRequest.cpp), there
is a call to the inspector like this:
    page->inspectorController()->resourceRetrievedByXMLHttpRequest(m_loader
? m_loader->identifier() : m_identifier, m_responseText);

The problem is that html 5 workers (and their XHR request code) don't run on
the main thread.  My fix for this was to send this information back to the
main thread and do the call to inspector there.  Unfortunately, this
involves making a copy of m_responseText and m_responseText may be quite
large, so this could be a bit perf hit.

Proposal
I'm not sure.  There are several ideas that I thought about but none that
I'm satisfied with:

1. Make the call resourceRetrievedByXMLHttpRequest thread safe.
    I suspect this may not be feasible due to the amount of work (but I
haven't investigated this possibility in any depth).

2. Only send the message to call resourceRetrievedByXMLHttpRequest back to
the main thread (and do the copy of m_responseText) when the inspector is
enabled.

This has two downsides:
a. The value of InspectorController::enabled may change after the Worker has
started so the Worker would need to track that value.  (Not too big of a
deal but it does make the code slightly more complicated.)
b. (Bigger issue) Nearly all developers will have the inspector enabled so
this means that the code path will be significantly different for developers
and most users.


I'm hoping others may have some ideas or suggestions about what to do here.

Thank you very much,
Dave

PS If you need/want more details of code, here's a possible patch that does
"2" (in part -- It doesn't yet track changes in the value of
InspectorController::enabled) --
https://bugs.webkit.org/attachment.cgi?id=26246&action=diff
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20081230/ebc57e8c/attachment.html>


More information about the webkit-dev mailing list