Re: What to do about cx parameter in infallible public API?

[Luke Wagner]

> They need to be in the same runtime because they can share objects,
> but they need to be in different contexts because ... I dunno...maybe
> they need different standard classes for security sandboxing?

You are correct in not knowing, because there essentially no need :) A context doesn't contain anything nor is anything 'bound to' or 'inside' a context (logically or technically). A context just maintains JS execution state. The execution state that makes sense is:
- current script/line
- the associated chain of calls to the current script/line
- a possible exception in progress (that needs to be propagated or reported by the JSAPI caller)

Unfortunately, there is more state:
- the global to use if nothing is running (JS_GetGlobalObject)
- the default version to use when compiling scripts

(The former has a bug to remove (bug 604813) and the latter could probably be removed by switching callers to the explicitly versioned APIs cdleary added (e.g. JS_CompileScriptForPrincipalsVersion).)

So that makes a context essentially a callstack. That means one thing you *can* do with multiple contexts on the same thread is to create multiple interleaved JS callstacks:

+-------------+
V | cx2
f1 <-- f2 f3 <-- f4 f5 <-- f6 f7 <-- f8
^ cx1 |
+------------+

(Note that this interleaving is still LIFO wrt the C callstack; this is not a way to "suspend and set aside" JS execution). However, we can easily support this sort of interleaved JS callstack without JSContext by giving JS_CallFunction/JS_ExecuteScript/JS_EvaluateScript a 'prev' argument.

Thus, my recommendation is, unless you need interleaved callstacks (incidentally, Firefox does to a degree) to keep a 1:1 mapping (JSRuntime <--> JSContext).

Also, I am in favor of eventually removing JSContext altogether (bug 650361) once all the above JSContext-neutering changes are made. (Passing a JSRuntime* instead of JSContext* seems favorable to passing nothing and having a "one JSRuntime per HW thread" rule that lets us remember the JSRuntime* in TLS.)

Cheers,
Luke

[Igor Bukanov]

On 7 February 2012 17:04, Luke Wagner <lu...@mozilla.com> wrote:
>  (Passing a JSRuntime* instead of JSContext* seems favorable to passing nothing and having a "one JSRuntime per HW thread" rule that lets us remember the JSRuntime* in TLS.)

I think this has to be considered case-by case basis. I suspect that
for API that can trigger a JS execution it would be still desirable to
have some form of mini-cx struct to store JS exception information or
to perhaps implement some security policies. But such mini-cx could be
allocated on the stack.