On 9/12/16 4:21 PM, Jim Blandy wrote:
So, in this pattern, if the target thread's execution of SomeRunnable::Run
could fail, causing ~SomeRunnable to call mMyRef's destructor and thus free
the referent on the target thread, that would be a bug?
Yes, it would.
-Boris
___
So, in this pattern, if the target thread's execution of SomeRunnable::Run
could fail, causing ~SomeRunnable to call mMyRef's destructor and thus free
the referent on the target thread, that would be a bug?
On Mon, Sep 12, 2016 at 12:47 PM, Boris Zbarsky wrote:
> On 9/12/16 3:40 PM, Jim Blandy w
On 9/12/16 3:40 PM, Jim Blandy wrote:
Could you go into more detail here? Either the caller will free it, or the
callee will free it --- but they're both on the same thread.
We have this pretty common pattern for handing references around threads
safely:
Main thread:
RefPtr runnable = new
On Mon, Sep 12, 2016 at 12:22 PM, Boris Zbarsky wrote:
It brings up one potential concern with Move: since the
>
>> callee might not take the value (intentionally or unintentionally), the
>> caller must *refrain* from caring about the state of its Move()'d
>> variable, between the Move() operatio
On 09/12/2016 12:22 PM, Boris Zbarsky wrote:
> It's worse than that. For a wide range of callers (anyone handing the
> ref across threads), the caller must check immediately whether the
> callee actually took the value and if not make sure things are released
> on the proper thread...
Ah, ok; I c
On 9/12/16 3:18 PM, Daniel Holbert wrote:
(1) They guard against leaks from unused already_AddRefed.
(2) They guard against logic errors where we should've taken the value
but forgot to do so. (And it enforces that callees must take the value,
even if they have some error handling cases where
On 09/12/2016 11:00 AM, Boris Zbarsky wrote:
> On 9/12/16 1:53 PM, Daniel Holbert wrote:
>> (I believe we have the "already_AddRefed as a parameter" pattern in our
>> code in order to avoid an extra addref/release when ownership is being
>> transferred into a function.
>
> And assertions if the fu
On 9/12/16 1:53 PM, Daniel Holbert wrote:
(I believe we have the "already_AddRefed as a parameter" pattern in our
code in order to avoid an extra addref/release when ownership is being
transferred into a function.
And assertions if the function does not actually take the reference...
But, Ref
On Mon, Sep 12, 2016 at 10:53 AM, Daniel Holbert wrote:
> On 08/12/2014 07:59 AM, Benjamin Smedberg wrote:
>> But now that nsCOMPtr/nsRefPtr support proper move constructors, [...]
>> Could we replace every already_AddRefed return value with a nsCOMPtr?
>
> I have a variant of bsmedberg's original
On 08/12/2014 07:59 AM, Benjamin Smedberg wrote:
> But now that nsCOMPtr/nsRefPtr support proper move constructors, [...]
> Could we replace every already_AddRefed return value with a nsCOMPtr?
I have a variant of bsmedberg's original question here. He asked about
return values, but I'm wondering:
On 09/09/2016 13:29, zbranie...@mozilla.com wrote:
The test at the moment is both noisy, and has a steady regression with each run
which makes it hard to feel confident about it and also makes it impossible to
just increase the number of runs in order to increase significance and
reliability o
Hi everyone,
Here's the list of new issues found and filed by the Desktop Release QA
Team last week, *September 05 - September 09* (week 36).
Additional details on the team's priorities last week, as well as the
plans for the current week are available at:
https://public.etherpad-mozilla
12 matches
Mail list logo
