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

[Maciej Stachowiak]

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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20081231/f4d4872a/attachment.html>