talloc_tos() Re: 617ec07 ?

[Volker Lendecke]

On Wed, Aug 11, 2010 at 08:27:21AM +1000, Andrew Bartlett wrote:
> Honestly, I'm not a great fan of talloc_tos().  I've had it explained to
> me multiple times, and I appreciate that it both works and solves real
> world problems, but things like the SMB_ASSERT() on allocation failure
> and (more particularly) it being just a little bit opaque still makes me
> uncomfortable. 

What is opaque to you about talloc_tos()? It is a temporary
talloc context that is always around and that will get
free'ed at some point soon when you return the current
routine. When it is exactly free'ed, that is indeed opaque,
but you can be sure that it will be free'ed and not leak.

The point of talloc_tos() and talloc_stackframe() is that it
is defensive programming. In a perfect world, we would
always choose the right talloc context and free it. But as
we are all humans and make mistakes, talloc_tos() has
definitely avoided memory leaks.

Moreover, in Samba3 it has made a significant speed
improvement easy with a talloc_pool being used as the top
talloc stackframe per smb request. I know the argument that
we should improve and use our own malloc, but Samba is not
yet there to replace the system malloc with something more
efficient, and possibly it will never be.

So I would know if the uncertainty when a context is free'ed
is your only concern with talloc_tos() and if so what we can
do to overcome it.

Volker