Re: Cross-process JS wrappers

On 8/31/09 1:48 AM, Robert O'Callahan wrote:

> We need to think carefully about how JS run-to-completion semantics will
> work here. We can't allow arbitrary events to run in the content process
> between two synchronous JPW calls from the same chrome script execution.

We could! For a first pass at seeing how much of our Firefox/Fennec UI needs
to change I don't think we need to solve the run-to-completion problem. We
may not need to solve it at all, as long as extensions are willing to live
with occasional racy behavior.

> My idea was to effectively lock the content process until the chrome
> script has run to completion. E.g., handle the first JPW call in a
> content process by dispatching an event to the content process' main
> thread. That event would wait for and process any further JPW calls
> until the chrome script execution has completed, at which time the event
> returns to the content process' main thread event loop.

The easiest way to do this would be to lock the content process at the first
JPW call and unlock it when we get back to the main event loop (or some
kinds of nested event loops for modal dialogs). Determining when a
particular script has run to "completion" is oddly complicated given the way
we can walk through binary<->JS for a script.

> We also need to say something about timeouts --- if the content process
> is hung, how long do we wait before giving up, and what do we do? Just
> throw a JS exception?

Yes. We haven't determined the actual timeout delay yet, but it will
probably be similar for JPW and for the plugin messages, which are also
rpc-style.

--BDS