JS raw MIME parser prototype
pidgeot18 at gmail.com
Sat Jan 28 20:31:50 UTC 2012
On 1/28/2012 1:33 PM, Andrew Sutherland wrote:
> On 01/28/2012 05:27 AM, Robert Kaiser wrote:
>> Joshua Cranmer schrieb:
>>> 1. This parser is fully synchronous and blocking; the intent is to spin
>>> the event loop using the callback in getNextBuffer.
>> Hmm, is it designed in a way that could be run on a (Chrome)Worker
> It's always possible to just spin up your own thread and run JS in
> it. In that way it's very easy to expose whatever native functions
> into the global scope the code is running in. Using stock web workers
> and chrome workers could be more tricky.
> The main problem with stock workers is that I believe the only way
> they can receive things postMessage()d to them is after they have
> yielded control back to the event loop at which point they will
> receive the DOM event.
From my perspective, the main issue is that ChromeWorkers are pretty
emasculated beasts. The only escape hatch is ctypes (which is fairly
limiting, although there is an undocumented backdoor function that
allows me to pop around a JSRuntime ). I definitely need access to
C/C++ code to do charsets, and I need it via a backdoor that won't
scream bloody murder if it's not UTF-8. I don't trust XHR to not scream
as well, but given that I can use an ArrayBuffer as output, and also
given that the interface is being designed to assume that buffers are
not necessarily Strings, this shouldn't be a problem .
> Both web workers and chrome workers are capable of performing
> synchronous XHR's. Those will spin a nested event loop until they get
> their data. That still requires a URL that can serve up bytes.
> Luckily mailnews can already do this. Presumably if the request
> included some byte-range requests, that would be happy. The advantage
> over having another I/O sourcing thread just throwing things at the
> parsing thread is that the parsing thread is effectively pulling the
> I/O, which provides some built-in flow control
The C++ glue will be designed to be runnable on any nsIEventTarget, so
it's certainly possible to make a single parser thread.
 This, of course, assumes that the developers aren't going to try to
undo this backdoor. Given that it was initially installed for telemetry,
we should be safe; then again, they removed the use of XPCOM from
 Looking through some of the interfaces, nsIDOMFileReader has a
readAsBinaryString, which does no charset conversion. Since XHR (and the
file APIs) allow me to get a Blob to stuff into nsIDOMFileReader, that's
one batch of worries down the drain.
News submodule owner
More information about the tb-planning