[PATCH] talloc_free_for_exit() and targeted write protection for talloc destructor

[Volker Lendecke]

On Tue, Nov 29, 2016 at 08:13:26PM +1300, Andrew Bartlett wrote:
> On Tue, 2016-11-29 at 07:57 +0100, Volker Lendecke wrote:
> > On Tue, Nov 29, 2016 at 07:13:53AM +1300, Andrew Bartlett wrote:
> > > 
> > > In a hope of getting more attention and being more transparent,
> > > here is
> > > the talloc changes I included in my previous patch set.
> > > 
> > > As background, I want to make our LDAP server multi-process, and
> > > running a connect()/bind()/close() loop against the LDAP server
> > > showed
> > > a significant cost in talloc_free(ev) and talloc_autofree() just
> > > before
> > > exit.
> > 
> > Question -- why don't you directly call exit() without the
> > talloc_free(ev)? Or even _exit()? We should be able to live with
> > crashed processes. What destructors are you missing?
> 
> I assumed there would at least be messaging database entries to un-
> register.  _exit() seemed a little extreme, but I agree it is an
> option, and of course exit() calls handlers registered with atexit().  
> 
> Memory on the autofree context from that atexit() registered call was
> around half the overhead in our examination of the flame graphs. 

As long as you have smbd running, the messaging database entries will
be cleaned up eventually. This is done in
messaging_parent_dgm_cleanup_init & friends. In the parent doing the
waitpid, you could also call messaging_cleanup() for the exited child
to make this deterministic.

Volker