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.
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
On Tue, May 13, 2014 at 8:20 AM, Ehsan Akhgari ehsan.akhg...@gmail.comwrote:
On Tue, May 13, 2014 at 2:37 AM, Rik Cabanier caban...@gmail.com wrote:
On Mon, May 12, 2014 at 10:15 PM, Joshua Cranmer pidgeo...@gmail.com
wrote:
On 5/12/2014 7:03 PM, Rik Cabanier wrote:
*Concerns*
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.
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 caban...@gmail.com wrote:
On Tue, May 13, 2014 at 8:20 AM, Ehsan Akhgari ehsan.akhg...@gmail.com
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
On 2014-05-13, 10:54 AM, Eli Grey wrote:
On Tue, May 13, 2014 at 1:43 PM, Ehsan Akhgari ehsan.akhg...@gmail.com 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
On Tue, May 13, 2014 at 1:43 PM, Ehsan Akhgari ehsan.akhg...@gmail.com 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)
On Tue, May 13, 2014 at 1:57 PM, Ehsan Akhgari 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 higher priority, it's unavailable by definition.
Run this
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
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
On 2014-05-13, 11:14 AM, Eli Grey wrote:
On Tue, May 13, 2014 at 1:57 PM, Ehsan Akhgari ehsan.akhg...@gmail.com
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
-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
avoided
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
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
On Mon, May 12, 2014 at 9:36 AM, Kyle Huey m...@kylehuey.com 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
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
Brian Smith wrote:
On Mon, May 12, 2014 at 9:36 AM, Kyle Huey m...@kylehuey.com 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
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
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
20 matches
Mail list logo
