PATCH: Re: talloc -- Eureka*

[Stefan (metze) Metzmacher]

Hi Sam,

> Attached are some "talking about" patches.
> 
> If the approach is suitable then I'll rework them based on Metze's
> edition of my patches in his WIP tree.

I don't think we should base on my no_owner code.

I have done some modifications to make talloc_steal never fail
as before on top of the current master. We have really to much
callers of talloc_steal() which rely on it to never fail.
I think it's ok to print out a warning instead of generating an error
if talloc_steal() is used together with references.

And I added infrastructure to set a real log function (we can expand it
to use vargs if wished). (I still need to set them up for samba).

See the top 3 commits here (the others have nothing to do with this
discussion):
http://gitweb.samba.org/?p=metze/samba/wip.git;a=shortlog;h=refs/heads/master4-talloc-metze-3

> The first patch adds talloc_reference_sticky and
> talloc_increase_ref_count_sticky

What about adding your sticky code above my new branch?
And please use 'sticky' instead of slippy in all places:-)
(there's also a typo, you always pass 'sticky == false')

> The second patch tries to bring in Tridges patch.
> It adds a function slippy_ref; Tridge had been adding warnings/failures
> on tc->refs != NULL.
> 
> I replace this with slippy_ref(tc) which returns the first non-sticky
> ref from tc->refs.
> 
> If there are more than one non-sticky parent, then Tridge's code will
> fail as he likes.
> 
> Coders who avoid the old slippy references don't need to worry about
> talloc_free failing.
> 
> I think non-sticky references are an abomination, but I'm glad that now
> any sticky references I take will be safe.

I think this sticky references should only went away with
talloc_unlink() or the implicit via the reference parent being free'ed.

metze

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 252 bytes
Desc: OpenPGP digital signature
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20090729/c66e7271/attachment.pgp>