Do we really need the ForThread part? Is the long term plan to merge JSRuntime and JSContext, or are they going to remain distinct indefinitely?
- Kyle On Sun, May 29, 2016 at 6:10 PM, Boris Zbarsky <bzbar...@mit.edu> wrote: > We currently have the following functions in nsContentUtils for getting > various JSContexts: > > GetSafeJSContext() > GetDefaultJSContextForThread() > RootingCx() > RootingCxForThread() > > We also have workers::GetCurrentThreadJSContext() for use on workers only. > > Now that we're about to move to only having one JSContext per thread (see > bug 1276276) I think we should do some consolidating and renaming here. In > particular, we should stash the unique JSContext for the thread in the > CycleCollectedJSRuntime and have only one accessor to get it, which goes > through CycleCollectedJSRuntime::Get(). This does mean a TLS lookup in some > cases in which right now we just do a pointer-chase, but has the benefit of > simplicity. And if we ever add non-worker threads with DOM stuff on them > (which we're talking about anyway), we'd want this no matter what. > > My proposal is that we name this accessor something like > JSContextForThread(). We can put this in nsContentUtils, in the > "mozilla::dom' namespace, or the "xpc" namespace... I don't have a strong > preference here. > > If we _really_ want to we can keep a RootingCxForThread() around which > returns exactly the same thing as JSContextForThread() but makes it clear > that we plan to use it for rooting only. I think we should nix RootingCx(). > > Thoughts? > > -Boris > _______________________________________________ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
