On Dec 30, 2008, at 11:14 AM, David Levin wrote:
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.
Most of the time, m_responseText won't even get used by the inspector.
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).
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
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.
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
complicated).
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.
Regards,
Maciej
_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
