JS raw MIME parser prototype

Joshua Cranmer 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 
>> thread?
> 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 [1]). 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 [2].

> 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.

[1] 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 
[2] 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.

Joshua Cranmer
News submodule owner
DXR coauthor

More information about the tb-planning mailing list