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 can see that complicating the logic in the caller considerably, if the caller really had to worry about that. Seems like we should enforce that callees must do the cleanup in that sort of case (and already_AddRefed does indeed enforce that, which is nice). >> I guess my bottom-line question is: which pattern should I prefer, for >> new code that wants to trivially transfer ownership of a refcounted >> object into a function or a constructor? > > Are threads involved? ;) Nope! > My gut feeling is that we should use the safer pattern with > already_AddRefed just so people don't start using the other pattern in > anything resembling multithreaded code, though in your particular case > both patterns would be fine... OK, that's reasonable -- thanks. ~Daniel P.S. As I realized when replying to khuey -- part of my motivation here was for consistency with UniquePtr, where the documentation/best-practices explicitly call for using Move() and UniquePtr&& to transfer ownership. It seems like it'd be nice if our other smart pointer types could have consistent best-practices for similar operations. But, maybe that's asking too much, in the presence of these thread complications. :) _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
