On Thu, Jan 7, 2016 at 6:47 AM, Karl Tomlinson <mozn...@karlt.net> wrote: > Xidorn Quan writes: > >> On Wed, Jan 6, 2016 at 3:53 AM, Kyle Huey <m...@kylehuey.com> wrote: >>> On Mon, Jan 4, 2016 at 4:10 PM, Randell Jesup <rje...@jesup.org> wrote: >>>> >>>> Yup. In cases where we anticipate a possible Dispatch failure (which is >>>> supposed to become impossible, but isn't currently) you can use the >>>> (still-existing) raw ptr interface and handle Dispatch failure >>>> explicitly to release the (leaked) reference, if it's safe. Not all >>>> cases are safe to release in that case (which is what drove the initial >>>> bug filing, where it tried to release JS objects on Dispatch failure off >>>> mainthread). Leaking is better than crashing/sec-bugs. >>> >>> No, you can't. If you can the raw ptr interface today Dispatch will >>> create its own reference and pass that to the already_AddRefed version >>> which then leaks it. There's no way for the caller to handle this >>> safely. Again, as karlt points out, Dispatch leaks today even if the >>> caller does everything correctly. >> >> 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. 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. Wrapping the hack in a desent interface is the best way to go. - Xidorn _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
