On 4/21/10 5:36 PM, johnjbarton wrote:
> I gather then that each jetpack will get its own process? Or is there
> a jetpack process for every content process? What part of the jetpack
> will be in content process and what part not? The proposal says:
> The jetpack JS itself will run in the content process.
Good catch, that was a bug. The jetpack JS will run in the jetpack process.
The current plan is to have each jetpack run in its own process, but its
possible that we could share a process for several jetpacks, if the startup
or memory overhead is too high. That can be measured/tuned, just as we've
done for plugins.
> Unlike plugins, jetpack will be hooked into the web page: killing the
> process by user or accident will leave the page mods and hooks in
> place with nothing to back them.
This is very similar to plugins, in fact. We don't expect users to kill
plugins or jetpacks under normal circumstances, but we would like to be able
to tell the user exactly how much CPU and memory a plugin or jetpack is
responsible for, and processes provide a simple an accurate measure.
> Was there discussion of alternative approaches which could result in
> similar user values? In particular, users don't want to kill jetpacks,
> they want jetpacks that work. (Most) jetpacks on firefox are not
> likely to act like applications on operating systems: they modify the
> content or the chrome or both. Collaborative testing and improved
> application monitor tools might provide robust higher performance
> application experiences than isolation and kill approaches.
Yes. It is clearly desirable that neither jetpacks nor content be able to
block the application UI. This can be accomplished with threads or with
processes. Given the way things are structured, processes are a more
practical solution than threads.
If you'd like to counter-propose some other mechanism, I'm happy to discuss
it, but this planning has been going on for a while and I really don't want
to start back at first-principles.
> Ok, but the wiki page does not reference anything about that stuff,
> which was my point.
This was describing the API that will available to JEP implementations, not
the underlying details about how that will be done.