On 13/03/2016 09:22, Kyle Huey wrote: > Much of the "disease" you see is simply support for DOM worker threads, > because every runnable that can run on those threads must be > cancelable. Workers do not guarantee one of the invariants that other > XPCOM threads do: that every runnable is eventually run after being > successfully dispatched. Instead we guarantee that every runnable is > either Run() or Cancel()ed.
Yeah, that's something I had noticed and I was trying to understand why. So it seems that this interface actually turned out to have a proper use after all. > The disadvantage of pushing this into the event queue is that today > runnables that are dispatched from other threads to workers *must* > implement nsICancelableRunnable, which means authors of code that runs > on workers must think about this. We do already have an exception for > NS_DispatchToCurrentThread though (via ExternalRunnableWrapper), so this > may be something we can relax. It would generally require us to write > cleanup code (for the existing runnables and any future ones) to run > from destructors, and historically destructors could run on either the > dispatching thread or the executing thread (although that has changed > somewhat.) My gripes with its original design is that it's inherently non-thread-safe and non-atomic (i.e. Cancel() can be called while Run() is being executed) and it essentially drops the burden of implementing proper cancellation on the user. My idea of handling cancellation externally was motivated by having the operation be both thread-safe and fully atomic (either something runs or it doesn't). This however implies that if the task was fire-and-forget, then destruction will always be done by the canceling thread and will happen immediately; in the current scenario destruction will be done by the thread owning the queue, and it will happen only when the runnable is drained from it. > Regardless, your plan should probably involve me ;) Yeah, this was my idea when nsICancelableRunnable was practically only used in FxOS-specific code to support canceling potentially long-running operations posted on the main thread (and which might have not executed yet). Since it's use has evolved it might not be worth pursuing it anymore, which is why I wanted to hear about how it's been used now. > PS. Subscribe to the mailing list so you don't get caught in moderation. I'm already subscribed, I just verified it, it's bizarre that the message was held :-/ Gabriele
signature.asc
Description: OpenPGP digital signature
_______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
