| moz.build |
|
1008 |
| tests |
|
|
| XMLHttpRequest.cpp |
static |
2336 |
| XMLHttpRequest.h |
|
7329 |
| XMLHttpRequestEventTarget.cpp |
|
1473 |
| XMLHttpRequestEventTarget.h |
|
1524 |
| XMLHttpRequestMainThread.cpp |
|
140173 |
| XMLHttpRequestMainThread.h |
Xlib headers insist on this for some reason... Nuke it because
it'll override our member name |
28620 |
| XMLHttpRequestString.cpp |
|
5557 |
| XMLHttpRequestString.h |
The existing length of the string. Do not call during BulkWrite().
|
4028 |
| XMLHttpRequestUpload.cpp |
virtual |
950 |
| XMLHttpRequestUpload.h |
|
1180 |
| XMLHttpRequestWorker.cpp |
XMLHttpRequest in workers
XHR in workers is implemented by proxying calls/events/etc between the
worker thread and an XMLHttpRequest on the main thread. The glue
object here is the Proxy, which lives on both threads. All other objects
live on either the main thread (the XMLHttpRequest) or the worker thread
(the worker and XHR private objects).
The main thread XHR is always operated in async mode, even for sync XHR
in workers. Calls made on the worker thread are proxied to the main thread
synchronously (meaning the worker thread is blocked until the call
returns). Each proxied call spins up a sync queue, which captures any
synchronously dispatched events and ensures that they run synchronously
on the worker as well. Asynchronously dispatched events are posted to the
worker thread to run asynchronously. Some of the XHR state is mirrored on
the worker thread to avoid needing a cross-thread call on every property
access.
The XHR private is stored in the private slot of the XHR JSObject on the
worker thread. It is destroyed when that JSObject is GCd. The private
roots its JSObject while network activity is in progress. It also
adds itself as a feature to the worker to give itself a chance to clean up
if the worker goes away during an XHR call. It is important that the
rooting and feature registration (collectively called pinning) happens at
the proper times. If we pin for too long we can cause memory leaks or even
shutdown hangs. If we don't pin for long enough we introduce a GC hazard.
The XHR is pinned from the time Send is called to roughly the time loadend
is received. There are some complications involved with Abort and XHR
reuse. We maintain a counter on the main thread of how many times Send was
called on this XHR, and we decrement the counter every time we receive a
loadend event. When the counter reaches zero we dispatch a runnable to the
worker thread to unpin the XHR. We only decrement the counter if the
dispatch was successful, because the worker may no longer be accepting
regular runnables. In the event that we reach Proxy::Teardown and there
the outstanding Send count is still non-zero, we dispatch a control
runnable which is guaranteed to run.
NB: Some of this could probably be simplified now that we have the
inner/outer channel ids.
|
73252 |
| XMLHttpRequestWorker.h |
|
8598 |