[Development] Qt's Leak-on-exit policy

[Allan Sandfeld Jensen]

On Thursday 19 December 2013, Andreas Hartmetz wrote:
> On Wednesday 18 December 2013 09:34:37 Sorvig Morten wrote:
> > On 18 Dec 2013, at 01:22, Thiago Macieira <thiago.macieira at intel.com> 
wrote:
> > > If it turns out that the failure to destroy is harmless, I'm not sure
> > > we should do anything. If it's harmless, that means the extra work
> > > required to
> > > free the memory is wasted, since it has no benefit to anyone. Just
> > > wasted CPU cycles.
> > 
> > An interesting trend on the Apple platforms is not having a clean app
> > shutdown. The OS will terminate the process when the user indicates it’s
> > no longer in use, for example by switching to another app or closing all
> > the application windows.
> > 
> > This suggests two levels of support from Qt:
> > 
> > 1) Support a clean shutdown for applications and/or operating systems
> > that require this. We go the extra mile to make sure Qt works well with
> > leak detecting tools.
> > 
> > 2) Support “process terminate” style shutdown for applications that
> > require a fast shutdown. This shutdown could be initiated by the OS or
> > by the application. The requirements for this lie in the area of the
> > application not doing much processing on shutdown (auto-saving settings
> > immediately for example), and Qt protecting itself from termination
> > during critical operations such as writing QSettings to disk or having a
> > background file transfer in progress.
> 
> Hello.
> This is not supposed to be a serious contribution to the discussion.
> This is about an unworkable but fun idea.
> 
> 2) reminds me of a crazy idea I've had once... freeing memory (not
> object destruction!) at application exit really serves no other purpose
> than making leak checkers happy. Not saying that this isn't an
> important goal, btw. So shutdown could be accelerated by putting
> free() into a special shutdown mode that just immediately returns.
> Of course there would be a conditional branch somewhere, unless you
> modified the GOT entry for free() or something. That would add a
> runtime overhead, which is worse than slightly slower shutdown.
> 
> I don't even know how much time is spent in free() at shutdown, and
> faster shutdown isn't a very important goal anyway.
> Instantaneous shutdown (see 2)) seems more useful in practice.

I just thought the same thing. Though it should not be a empty operation but a 
changed free() operation that cuts down the frequency of expensive 
maintainence like free-block coalescing, this could be very dependant on the 
malloc implementation and probably not doable generally.

Also I suspect most of the wasted time on shutdown is unwrapping all the 
layers of destructors, which we need to since the destructors might maintain 
state. Ideally C++ an attribute to indicate pure destructors that only free 
memory, as opposed to destructors with side-effects. Such a mechanism could 
also help diagnose if reachable static links are safe.

`Allan