(This is a continuation of the discussion in bug 1218297) In bug 1155059 we made nsIEventTarget::Dispatch take an already_AddRefed instead of a raw pointer. This was done to allow the dispatcher to transfer its reference to the runnable to the thread the runnable will run on. That solves a race condition we've had historically where the destructor of a runnable can run on either the dispatching thread or the executing thread, depending on whether the executing thread can run the event to completion before the dispatching thread destroys the nsCOMPtr on the stack. So far, so good.
In bug 1218297 we saw a case where dispatch to a thread (the socket transport service thread in this case) fails because the thread has already shut down. In our brave new world, nsThread simply leaks the runnable. It can't release the reference it holds, because that would reintroduce the race condition we wanted to avoid, and it can't release the reference on the correct thread so it's already gone away. But now we have a new source of intermittent leaks. Was this anticipated when designing bug 1155059? I don't think leaking is acceptable here, so we may need to back that out and return to living with that race condition. - Kyle _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
