On 12/14/12 1:48 AM, Justin Lebar wrote:
FWIW, I once tried changing all of our atomic string refcounting to
non-atomic operations and could not eke out a performance (or
stability) difference on x64. This was despite the fact that I was
able to generate profiles where the atomic string refcount
> Is code like this safe in the C++1 Unordered model?
> Thread 1:
> int x = obj->v;
> obj->Release();
> Thread 2:
> obj->Release();
> where obj's destructor trashes obj->v.
> The potential hazard is if thread 1's obj->Release() atomic decrement is
> reordered to run before the obj->v load has
Henri Sivonen wrote:
> > Fonts are loaded when used so font loading won't start until the
> > contents using a particular font are laid out.
>
> That seems like a problem for JS-driven display. A big problem in
> the canvas case and at least an annoyance when a JS program drives
> the input to C
On Fri, Dec 14, 2012 at 12:33 PM, Joshua Cranmer wrote:
> 3. Similar to #2, the ideal version of a reference counter would be
> mozilla::Atomic (which would make threadsafe
> refcounting cheaper on our ARM platforms if we compiled with gcc 4.6 or
> clang 3.1 or newer). However, I'm not sure that n
As you may or may not be aware, one of the goodies that comes in C++11
is the introduction of an explicit memory model as well as proper
support for multithreaded code. One important piece of this is
std::atomic, which provides an interoperable way to do (potentially
lockless) atomic operations
On 12/12/12 19:06, Justin Lebar wrote:
Recently I read Dave Townsend's thread about "Super-review,
what shall we do with you?" and realized there wasn't any
conclusion to that.
As a relative new dev, I think it is vital to have a clear
distinction as to when a sr is required.
I think the concl
On 11/12/12 06:40, Henri Sivonen wrote:
> On Sat, Dec 8, 2012 at 5:24 PM, Randell Jesup wrote:
>> tl;dr - prefixing is bad. It's not good even before Release. API
>> version suffixing may be better.
>
> Are you OK with the latest policy proposal I made or do you intend to
> make a counter-propo
Robert O'Callahan a écrit :
Often, the OS support for a particular
language is really terrible and we can and should do better even if it
means being inconsistent with the OS. This is certainly true for the case
of font shaping, for example.
I've seen the references to font shaping in the start
8 matches
Mail list logo
