svn commit: samba r23290 - in
branches: SAMBA_3_0/source/nsswitch SAMBA_3_0_26/source/nsswitch
simo
idra at samba.org
Sat Jun 2 19:30:39 GMT 2007
On Sat, 2007-06-02 at 12:02 -0700, Jeremy Allison wrote:
> On Sat, Jun 02, 2007 at 02:51:46PM -0400, simo wrote:
> >
> > You definitively must be careful.
> > Since I started working with the new talloc I decided to change my
> > mindset. Now I give for granted that if I have a structure and I have to
> > allocate stuff in it, then the memory hierarchy follows the structure I
> > am using.
>
> I think you're correct here - this is the only
> way to go. How do you deal with this when you have complex
> dependencies between the structures though, such
> as the winbindd ones ?
First answer: Magic ;-)
More seriously, it really depends.
Sometimes I decide based on the way this stuff need to be set free.
That's another good way to group stuff.
Put all the stuff you know have to be talloc_free()ed at the same time
hanging on the same context. And in some rare cases you have to change
the way the code is done.
I had this problem in ldb, we didn't have the right handle to hang
memory on. But one thing was clear, in 99.9% of the cases once a request
was finished, I needed to free all the memory used.
What I did was to change the request structure and functions beneath so
that all memory, ultimately, would be attached to the requests, and when
a request is finished all I have to worry about is to do a
talloc_free(request); no matter how deep that structure have been passed
down (many modules, the core tdb/ldap/sqlite backend and then back).
At that point, I am reasonably sure all the memory that have to be
released is indeed released, no matter what, the hierarchy insures this.
And if there are cases where I know something must not be released, well
then it is easy to do a talloc_steal/talloc_move of only the
sub-structure I need and hang it on a longer lived context like the
ldb_context or a module private_data structure or something else.
Simo.
--
Simo Sorce
Samba Team GPL Compliance Officer
email: idra at samba.org
http://samba.org
More information about the samba-technical
mailing list