JS raw MIME parser prototype

Andrew Sutherland asutherland at asutherland.org
Sat Jan 28 19:33:56 UTC 2012

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 

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

Chrome workers can also get at js-ctypes, which does provide various 
options that would allow for a more direct API to interact with the 
mailnews backend, although I'm unclear on whether js-ctypes is allowed 
to request symbols out of the running libxul and access its statics... I 
would assume so.

The other option is if the dom/workers/ implementation exposes any of 
its API, we might be able to get at the JS runtime/context/compartment 
that way and be able to introduce globals that way.  We might also be 
able to petition such API exposure if it doesn't exist.


More information about the tb-planning mailing list