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. _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
