Re: Gecko shutdown (London session)

Hi Aaron, others, On Thu, Jun 30, 2016 at 8:41 AM, 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

Re: Gecko shutdown (London session)

On 06/30/2016 11:49 AM, Nicolas Silva wrote: Hi dev-platform, We had a session about shutdown problems during the London workweek. I did a writeup of what was discussed and as it grew into a large-ish piece, I put it in a wiki page (instead of the email I intended to send initially) [1].

Re: Gecko shutdown (London session)

On Thu, Jun 30, 2016 at 8:41 AM, 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, >

Re: Gecko shutdown (London session)

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

Re: Gecko shutdown (London session)

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

Re: Gecko shutdown (London session)

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,

Re: Gecko shutdown (London session)

On Thu, Jun 30, 2016, at 04:35 PM, smaug wrote: > Not sure if this matters here, but cycle collector doesn't really retain > objects. Sure, we could explicitly clear so called jsholders, so that > C++->JS > edges are manually cut. But in general, CC doesn't know about a cycle > collectable

Gecko shutdown (London session)

Hi dev-platform, We had a session about shutdown problems during the London workweek. I did a writeup of what was discussed and as it grew into a large-ish piece, I put it in a wiki page (instead of the email I intended to send initially) [1]. There's been a lot of work on reducing shutdown