Cool, thanks for the refresh on those details. Clearly this still
involves a bunch of work, but so would any other shutdown improvement
project.
My concern is that if we are going to reexamine shutdown, then I think
that exit(0) needs to fit into this somehow. If we're going to spend the
resources to refactor a bunch of stuff in the shutdown sequence, we're
not maximizing the benefit to the user without it.
On 6/30/2016 9:44 AM, David Rajchenbach-Teller wrote:
There were plenty of blockers for _exit(0), including the fact that
pretty much none of the async code in Firefox/Gecko was shutdown-safe.
That's one of the reasons we had to come up with
nsIAsyncShutdown/AsyncShutdown.jsm. One of the not-entirely-stated goals
was that once everything registered with AsyncShutdown had finished
shutting down, we could call _exit(0).
Cheers,
David
On 30/06/16 17:41, Aaron Klotz wrote:
Did the now-defunct exit(0) project ever come up in this discussion?
See bugs 662444 and 826143. This was a perf team project back in the
Snappy days where the objective was to write important data to disk
ASAP, then exit(0) without doing a bunch of cleanup. The argument for
this was that, yes, during development we want to make sure that we are
properly cleaning up after ourselves, but there is no reason for end
users with opt builds to be waiting around while Firefox spends a bunch
of time destroying things that are going to be wiped anyway by process
termination.
Aaron
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
