Re: How to name our JSContext getter(s): let the bikeshed begin

2016-05-31 Thread Boris Zbarsky
On 5/30/16 12:55 PM, Kyle Huey wrote: Segregating the thread-specific and thread-agnostic parts into separate classes seems like a good idea. Just to be clear, that's pretty much all internal stuff. From the perspective of an API consumer (Gecko), there is really only the thread-specific thi

Re: How to name our JSContext getter(s): let the bikeshed begin

2016-05-30 Thread Kyle Huey
On Sun, May 29, 2016 at 6:21 PM, Boris Zbarsky wrote: > On 5/29/16 6:17 PM, Kyle Huey wrote: >> >> Do we really need the ForThread part? > > > I wanted to make it clear that we're getting something that's OK to use > without synchronization, but maybe that's redundant and we can just have a > dom:

Re: How to name our JSContext getter(s): let the bikeshed begin

2016-05-30 Thread smaug
On 05/30/2016 05:46 AM, Boris Zbarsky wrote: On 5/29/16 6:21 PM, Boris Zbarsky wrote: I wanted to make it clear that we're getting something that's OK to use without synchronization, but maybe that's redundant and we can just have a dom::GetJSContext() or something. dom::JSContext() would have

Re: How to name our JSContext getter(s): let the bikeshed begin

2016-05-29 Thread Boris Zbarsky
On 5/29/16 6:21 PM, Boris Zbarsky wrote: I wanted to make it clear that we're getting something that's OK to use without synchronization, but maybe that's redundant and we can just have a dom::GetJSContext() or something. dom::JSContext() would have ambiguity issues, of course. I don't have sup

Re: How to name our JSContext getter(s): let the bikeshed begin

2016-05-29 Thread Boris Zbarsky
On 5/29/16 6:17 PM, Kyle Huey wrote: Do we really need the ForThread part? I wanted to make it clear that we're getting something that's OK to use without synchronization, but maybe that's redundant and we can just have a dom::GetJSContext() or something. dom::JSContext() would have ambigui

Re: How to name our JSContext getter(s): let the bikeshed begin

2016-05-29 Thread Kyle Huey
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 wrote: > We currently have the following functions in nsContentUtils for getting > various JSCon

How to name our JSContext getter(s): let the bikeshed begin

2016-05-29 Thread Boris Zbarsky
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