Xidorn Quan writes: > On Thu, Jan 7, 2016 at 6:47 AM, Karl Tomlinson <mozn...@karlt.net> wrote: >> Xidorn Quan writes: >> >>> You can keep a raw pointer yourself, and release it manually after you >>> find the dispatch fails, like what is done in >>> NS_DispatchToCurrentThread [1]. It is ugly, but it works and safe, >>> because Dispatch guarantees to leak when it returns failure code for >>> any async dispatch. >>> >>> [1] >>> https://dxr.mozilla.org/mozilla-central/rev/29258f59e5456a1a518ccce6b473b50c1173477e/xpcom/glue/nsThreadUtils.cpp#162-171 >> >> I think it would be much better to keep the sane ref-counting of >> the original implementation and add a different method for use when the >> thread is known to be in a state to accept new runnables but this >> method will assert and leak if the assumption was invalid. > > No, that would make the race condition inevitable.
The race condition is not inevitable, but it may exist where code is not managing thread/object lifetimes appropriately. The "different" method can be used where there is risk of that happening. The race condition only matters when the runnable holds references to objects that must be released on a certain thread. These situations need to be managed by the calling code regardless of whether the Dispatch() method would leak or not on failure to manage the object appropriately. Passing references to main thread objects on other threads is difficult and just leaking the objects is not the solution. We can however have a special method for these situations that catches coding failures in a safe manner, provided that behavior is not enforced on callers that want the runnable released. Having the Dispatch() methods not leak means we get the behavior one would expect, which is the behavior that it had until recently. No quirky Release() calls are required by the callers that can safely release their objects on any thread. > It is probably doable to return an already_AddRefed somehow, e.g. via > return value, or a pointer parameter. But it isn't really worth to do > so. Yes, not necessary because the caller has the option to hold a reference if any thread can release. > Wrapping the hack in a desent interface is the best way to go. I don't know what you have in mind here, but the point of this thread is that we don't have that now. _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
