JS raw MIME parser prototype
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
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