[PATCH] Remove all uses of talloc_autofree_context() from our code (except for test)

[Simo]

On Tue, 2017-07-25 at 13:04 -0700, Jeremy Allison via samba-technical
wrote:
> On Tue, Jul 25, 2017 at 09:58:06PM +0200, Volker Lendecke wrote:
> > On Tue, Jul 25, 2017 at 12:37:24PM -0700, Jeremy Allison wrote:
> > > > Does "smbcontrol smbd pool-usage" still work after this change?
> > > 
> > > No. If we're not using the global null_context within
> > > talloc anymore, then pool usage doesn't have a central
> > > place to track all allocations off it.
> > 
> > That's tough. I definitely want pool-usage to be available
> > everywhere
> > and always. When you need it, it's too late to activate it.
> 
> Having it available "everywhere and always" is inconsistent
> with the design criteria behind this patchset. For that you
> need a completely MT-safe talloc - you know it and I know it :-).

Jeremy,
we can still have it by having a pool of counters instead.

In the main thread you have a linked list of structs reachable from the
main thread. And only ever operated on with mutexes.

Each structs represents a thread and points to a thread bound variable
that is ever only touched by the thread.
This way you can use it from threads without locking.

The tricky part is reading it for reporting without locks, I leave that
as an exercise for the reader (use memory barriers).

Simo.

> If you'd have mentioned that in the beginning then I wouldn't
> have spent literally *months* of work getting this done and
> cleaning up the code to this state.
> 
> talloc_autofree_context() is my 'nested event loops' :-). Having
> it in the code hides real bugs and complicates memory management
> by giving a lazy option everyone uses. It's how we ended up
> with the module initialization mess and other design problems.
> 
> Is there some compromise we can come to of starting smbd
> with a --track-pool usage parameter ?
> 
> If you've got a leak that can be reproduced then it's usually
> possible to recreate it with a restart of the smbd binary.
> 
> Jeremy.
>