[webkit-dev] inspector calls from XHR running in a (html5) worker
mjs at apple.com
Wed Dec 31 09:13:49 PST 2008
On Dec 30, 2008, at 11:14 AM, David Levin wrote:
> In XMLHttpRequest::didFinishLoading (WebCore/xml/
> XMLHttpRequest.cpp), there is a call to the inspector like this:
> >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
Most of the time, m_responseText won't even get used by the inspector.
> 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).
I agree that this is not a good idea.
> 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
> 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.
Indeed, those are two serious downsides.
> I'm hoping others may have some ideas or suggestions about what to
> do here.
I don't believe the m_responseText string will be modified by either
side, so making the call on a background thread without copying will
almost work, other than the threadsafety issue. Here's some possible
alternatives that avoid the copy:
A) Change resourceRetrievedByXMLHttpRequest to expect a handle to
later asynchronously receive the response text, rather than getting it
immediately - that way the copy only needs to be done on demand by the
worker thread (but the inspector's code could get a bit more
B) Make resourceRetrievedByXMLHttpRequest take a wrapper that locks
around all operations that may affect refcounting and lazily makes a
copy on demand when someone needs access to the raw underlying string
- the worker thread would have to use a similar wrapper.
C) Change the code to use a class with thread-safe refcounting in all
the places m_responseText would otherwise be used.
The basic idea here is that mutation is not a concern, only
refcounting, so making a copy of a potentially large string is
overkill and we should seek a solution narrowly tailored to the
threadsafety of recounting.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the webkit-dev