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

[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 super-strong opinions here.


Another thought that just occurred to me is ThreadCx().

-Boris
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to deprecate: MacOS 10.6-10.8 support

[Chris Pearce]

So, given that users won't be able to install Firefox on unsupported
versions of MacOSX, and unsupported users won't be upgraded, can we proceed
to remove all the nsCocoaFeatures::On[Mountain]LionOrLater() calls in
Firefox 49 and just assume everywhere that MacOSX specific Gecko code is
running on 10.9 or later?



On Fri, May 27, 2016 at 4:59 PM, Ralph Giles  wrote:

> On Thu, May 26, 2016 at 3:37 PM, L. David Baron  wrote:
>
> > There's a screenshot in:
> > https://bugzilla.mozilla.org/show_bug.cgi?id=1255588#c8 (and #c9)
> > (which is the bug that made the necessary changes for the Mac OS X
> > support change in Firefox 49).
>
> Ah, that's great. Thanks!
>
>  -r
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[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 
ambiguity issues, of course.  I don't have super-strong opinions here.



Is the long term plan to merge
JSRuntime and JSContext, or are they going to remain distinct
indefinitely?


Unclear.  See discussion the SpiderMonkey folks are having starting at 
https://bugzilla.mozilla.org/show_bug.cgi?id=650361#c27


-Boris
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[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 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

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

[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 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