Re: Request principal in nsIContentPolicy implementation

Hi Matthew, Are you using any other addons that could be calling into nsIContentPolicy? aRequestPrincipal is optional for non-gecko code, so perhaps another caller isn't setting it[1]? You can also get the principal off the Context[2][3]. Depending on what information you are trying to gat

Re: Intent to implement and ship: navigator.hardwareConcurrency

On Tue, May 13, 2014 at 3:16 PM, Ehsan Akhgari wrote: > >> ... >> >> >> That is not the point of this attribute. It's just a hint for the author >> so he can tune his application accordingly. >> Maybe the application is tuned to use fewer cores, or maybe more. It all >> depends... >> > > The probl

Re: Intent to implement and ship: navigator.hardwareConcurrency

As the main usage of this number is to maintain a fixed thread pool, I feel it might be better to have a higher level API, such as worker pool. I do agree that thread pool is very useful, but exposing the number of cores directly seems not to be the best solution. We could have a better abstractio

Re: nsRefPtr vs RefPtr

Brian Smith wrote: On Mon, May 12, 2014 at 9:36 AM, Kyle Huey wrote: We should get rid of RefPtr, just like we did the MFBT refcounting classes. The main thing stopping a mechanical search and replace is that the two smart pointers have different semantics around already_AddRefed/TemporaryR

Re: Intent to implement and ship: navigator.hardwareConcurrency

On Tue, May 13, 2014 at 2:59 PM, Boris Zbarsky wrote: > On 5/13/14, 2:42 PM, Rik Cabanier wrote: > >> Why would that be? Are you burning more CPU resources in servo to do the >> same thing? >> > > In some cases, possibly yes. > > > If so, that sounds like a problem. >> > > It depends on what you

Re: Intent to implement and ship: navigator.hardwareConcurrency

On 2014-05-13, 2:42 PM, Rik Cabanier wrote: On Tue, May 13, 2014 at 10:43 AM, Ehsan Akhgari mailto:ehsan.akhg...@gmail.com>> wrote: On 2014-05-13, 9:25 AM, Rik Cabanier wrote: Web applications can already do this today. There's nothing stopping them

Re: Intent to implement and ship: navigator.hardwareConcurrency

On 5/13/14, 2:42 PM, Rik Cabanier wrote: Why would that be? Are you burning more CPU resources in servo to do the same thing? In some cases, possibly yes. If so, that sounds like a problem. It depends on what your goals are. Any sort of speculation, prefetch or prerender is burning more C

Re: Intent to implement and ship: navigator.hardwareConcurrency

On Tue, May 13, 2014 at 10:43 AM, Ehsan Akhgari wrote: > On 2014-05-13, 9:25 AM, Rik Cabanier wrote: > >> Web applications can already do this today. There's nothing >> stopping them >> from figuring out the CPU's and trying to use them all. >> Worse, I think they w

Re: nsRefPtr vs RefPtr

On 2014-05-13, 11:46 AM, Tim Abraldes wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 The chromium IPC code is ours now, so we can mdify it as needed. Not sure about the Chromium sandbox code. The Chromium sandbox code lives at "security/sanbox" in the tree. AIUI, we wanted to be able to

MemShrink Meeting - Today, 13 May 2014 at 4:00pm PDT

Today's MemShrink meeting will be brought to you by correct use of the Gecko Cycle Collector: https://bugzilla.mozilla.org/show_bug.cgi?id=1004630 The wiki page for this meeting is at: https://wiki.mozilla.org/Performance/MemShrink Agenda: * Prioritize unprioritized MemShrink bugs. * Discuss

Re: nsRefPtr vs RefPtr

On Mon, May 12, 2014 at 9:36 AM, Kyle Huey wrote: > We should get rid of RefPtr, just like we did the MFBT refcounting classes. > > The main thing stopping a mechanical search and replace is that the > two smart pointers have different semantics around > already_AddRefed/TemporaryRef :( Nit: Ar

Re: Adding a recommendation that one-argument constructors be explicit to the C++ style guide

On 5/13/14, 7:47 AM, Benjamin Smedberg wrote: Seems there's general agreement. Please make this change to the style guide. Done. Added to https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Coding_Style#C.2FC.2B.2B_practices -Boris __

MemShrink Meeting - Today, 13 May 2014 at 4:00pm PDT

Today's MemShrink meeting will be brought to you by correct use of the Gecko Cycle Collector: https://bugzilla.mozilla.org/show_bug.cgi?id=1004630 The wiki page for this meeting is at: https://wiki.mozilla.org/Performance/MemShrink Agenda: * Prioritize unprioritized MemShrink bugs. * Discuss

Re: nsRefPtr vs RefPtr

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 > The chromium IPC code is ours now, so we can mdify it as needed. > Not sure about the Chromium sandbox code. The Chromium sandbox code lives at "security/sanbox" in the tree. AIUI, we wanted to be able to pull upstream changes easily so we've avoide

Re: Intent to implement and ship: navigator.hardwareConcurrency

On 2014-05-13, 11:14 AM, Eli Grey wrote: On Tue, May 13, 2014 at 1:57 PM, Ehsan Akhgari mailto:ehsan.akhg...@gmail.com>> wrote: No, you're wrong. An available core is a core which your application can use to run computations on. If another code is already keeping it busy with a hig

Re: nsRefPtr vs RefPtr

On 5/13/14 9:25 AM, Ehsan Akhgari wrote: The chromium IPC code is ours now, so we can mdify it as needed. Not sure about the Chromium sandbox code. Also AFAIK RefPtr was first incorporated into our code base as a way to replace wtf::RefPtr for YARR but I have no evidence that it actually ever

Re: Intent to implement and ship: navigator.hardwareConcurrency

Just wish to throw in my 2c... Many game engines will query the core count to determine if they should follow a simple (one main thread, one render thread, one audio thread, one streamer thread) or more parallel (multiple render threads, multiple audio threads, gameplay/physics/ai broken up in

Re: Intent to implement and ship: navigator.hardwareConcurrency

On Tue, May 13, 2014 at 1:57 PM, Ehsan Akhgari wrote: > No, you're wrong. An available core is a core which your application can > use to run computations on. If another code is already keeping it busy > with a higher priority, it's unavailable by definition. > Run this code

Re: Intent to implement and ship: navigator.hardwareConcurrency

Also note that even some popular desktop APIs that in practice expose the "hardware" thread count, choose not to call it that way. For example, Qt calls it the "ideal" thread count. http://qt-project.org/doc/qt-4.8/qthread.html#idealThreadCount IMO this suggests that we're not the only ones feel

Re: Intent to implement and ship: navigator.hardwareConcurrency

On Tue, May 13, 2014 at 1:43 PM, Ehsan Akhgari wrote: > supporting a worker pool that actually scales to how many cores you have > available 1) What is an "available core" to you? An available core to me is a core that I can use to compute. A core under load (even 100% load) is still a core I ca

Re: Intent to implement and ship: navigator.hardwareConcurrency

On 5/13/2014 12:35 PM, Eli Grey wrote: Can you back that up with a real-world example desktop application that behaves as such? The OpenMP framework? -- Joshua Cranmer Thunderbird and DXR developer Source code archæologist ___ dev-platform mailing l

Re: Intent to implement and ship: navigator.hardwareConcurrency

On 2014-05-13, 10:54 AM, Eli Grey wrote: On Tue, May 13, 2014 at 1:43 PM, Ehsan Akhgari wrote: supporting a worker pool that actually scales to how many cores you have available 1) What is an "available core" to you? An available core to me is a core that I can use to compute. A core under l

Re: Intent to implement and ship: navigator.hardwareConcurrency

On 2014-05-13, 10:44 AM, Rik Cabanier wrote: On Tue, May 13, 2014 at 9:55 AM, Tom Schuster mailto:t...@schuster.me>> wrote: I recently saw this bug about implementing navigator.getFeature, wouldn't it make sense for this to be like hardware.memory, but hardware.cores? Is this a

Re: Intent to implement and ship: navigator.hardwareConcurrency

On 2014-05-13, 10:35 AM, Eli Grey wrote: On Tue, May 13, 2014 at 11:20 AM, Ehsan Akhgari wrote: Can you please provide some examples of actual web applications that do this, and what they're exactly trying to do with the number once they estimate one? (Eli's timing attack demos don't count. ;-

Re: Intent to implement and ship: navigator.hardwareConcurrency

On Tue, May 13, 2014 at 9:55 AM, Tom Schuster wrote: > I recently saw this bug about implementing navigator.getFeature, wouldn't > it make sense for this to be like hardware.memory, but hardware.cores? > Is this a feature that is adopted across browsers? Interesting that Firefox exposes this. W

Re: Intent to implement and ship: navigator.hardwareConcurrency

On 2014-05-13, 9:55 AM, Tom Schuster wrote: I recently saw this bug about implementing navigator.getFeature, wouldn't it make sense for this to be like hardware.memory, but hardware.cores? No, because that would have all of the same issues as the current API. Cheers, Ehsan ___

Re: Intent to implement and ship: navigator.hardwareConcurrency

On 2014-05-13, 9:25 AM, Rik Cabanier wrote: Web applications can already do this today. There's nothing stopping them from figuring out the CPU's and trying to use them all. Worse, I think they will likely optimize for popular platforms which either

Re: Intent to implement and ship: navigator.hardwareConcurrency

On Tue, May 13, 2014 at 11:20 AM, Ehsan Akhgari wrote: > Can you please provide some examples of actual web applications that do > this, and what they're exactly trying to do with the number once they > estimate one? (Eli's timing attack demos don't count. ;-) One example of a website in the wil

Re: Intent to implement and ship: navigator.hardwareConcurrency

I recently saw this bug about implementing navigator.getFeature, wouldn't it make sense for this to be like hardware.memory, but hardware.cores? On Tue, May 13, 2014 at 6:25 PM, Rik Cabanier wrote: > On Tue, May 13, 2014 at 8:20 AM, Ehsan Akhgari >wrote: > > > On Tue, May 13, 2014 at 2:37 AM,

Re: Adding a recommendation that one-argument constructors be explicit to the C++ style guide

On 2014-05-13, 7:47 AM, Benjamin Smedberg wrote: On 5/12/2014 4:07 PM, Boris Zbarsky wrote: So I'd like to propose that our C++ style require one-arg constructors to be marked explicit unless there's a clear comment explaining why the constructor is implicit. Seems there's general agreement. P

Re: Intent to implement and ship: navigator.hardwareConcurrency

On Tue, May 13, 2014 at 8:20 AM, Ehsan Akhgari wrote: > On Tue, May 13, 2014 at 2:37 AM, Rik Cabanier wrote: > >> On Mon, May 12, 2014 at 10:15 PM, Joshua Cranmer 🐧 > >wrote: >> >> > On 5/12/2014 7:03 PM, Rik Cabanier wrote: >> > >> >> *Concerns* >> >> >> >> The original proposal required that a

Re: nsRefPtr vs RefPtr

On 5/13/2014 11:25 AM, Ehsan Akhgari wrote: The chromium IPC code is ours now, so we can mdify it as needed. Not sure about the Chromium sandbox code. Also AFAIK RefPtr was first incorporated into our code base as a way to replace wtf::RefPtr for YARR but I have no evidence that it actually eve

Re: nsRefPtr vs RefPtr

On 2014-05-12, 4:48 PM, Mike Hommey wrote: On Mon, May 12, 2014 at 04:46:18PM -0700, Kyle Huey wrote: On Mon, May 12, 2014 at 2:46 PM, Mike Hommey wrote: On Mon, May 12, 2014 at 09:36:22AM -0700, Kyle Huey wrote: We should get rid of RefPtr, just like we did the MFBT refcounting classes. The

Re: Intent to implement and ship: navigator.hardwareConcurrency

On Tue, May 13, 2014 at 2:37 AM, Rik Cabanier wrote: > On Mon, May 12, 2014 at 10:15 PM, Joshua Cranmer 🐧 >wrote: > > > On 5/12/2014 7:03 PM, Rik Cabanier wrote: > > > >> *Concerns* > >> > >> The original proposal required that a platform must return the exact > >> number > >> of logical CPU cor

Re: Adding a recommendation that one-argument constructors be explicit to the C++ style guide

On 2014-05-13, 10:47 AM, Benjamin Smedberg wrote: On 5/12/2014 4:07 PM, Boris Zbarsky wrote: So I'd like to propose that our C++ style require one-arg constructors to be marked explicit unless there's a clear comment explaining why the constructor is implicit. Seems there's general agreement.

Re: Intent to implement and ship: navigator.hardwareConcurrency

On Mon, May 12, 2014 at 10:15 PM, Joshua Cranmer 🐧 wrote: > On 5/12/2014 7:03 PM, Rik Cabanier wrote: > >> *Concerns* >> >> The original proposal required that a platform must return the exact >> number >> of logical CPU cores. To mitigate the fingerprinting concern, the proposal >> was updated so

Re: Adding a recommendation that one-argument constructors be explicit to the C++ style guide

On 5/12/2014 4:07 PM, Boris Zbarsky wrote: So I'd like to propose that our C++ style require one-arg constructors to be marked explicit unless there's a clear comment explaining why the constructor is implicit. Seems there's general agreement. Please make this change to the style guide. Anyo

Re: Adding a recommendation that one-argument constructors be explicit to the C++ style guide

On 2014-05-12, 1:07 PM, Boris Zbarsky wrote: Background: in C++, one-argument constructors are implicit. What this means is that given this class declaration: class Foo { public: Foo(int arg); passAFoo(const Foo& arg); }; This bit of C++: Foo foo(5); foo.passAFoo(10)

Re: nsRefPtr vs RefPtr

On 2014-05-12, 2:46 PM, Mike Hommey wrote: On Mon, May 12, 2014 at 09:36:22AM -0700, Kyle Huey wrote: We should get rid of RefPtr, just like we did the MFBT refcounting classes. The main thing stopping a mechanical search and replace is that the two smart pointers have different semantics aroun

Re: nsRefPtr vs RefPtr

Oh and regarding 3rd-party code, that is not a different problem from what we have already discussed above: The only hard constraint here is that some 3rd-party code does not want to depend on XPCOM. That's fine; as discussed above, we could easily move out of XPCOM (presumably into MFBT) the part

Re: nsRefPtr vs RefPtr

If the semantics difference between TemporaryRef and already_AddRefed are the main factor blocking us here, could we at least make progress by temporarily having the two coexist, i.e. a transition plan roughly as follows: 1) Introduce a nsTemporaryRef behaving like TemporaryRef but cooperating wi