the sorry saga of the talloc soname 'fix'

[Sam Liddicott]

* Michael Adam wrote, On 09/07/09 10:37:
>
> Hey, I am not questioning _your_ use of talloc_reference
> especially, but any use.
>
>   

It's an interesting discussion, but not one I attempt to address.
I'm just offering a fix to existing talloc functionality.

>> Why not just look at the fix? I'm using it, I have the benefitd, I'm
>> trying one more time to give it to Samba because could ALSO solves the
>> immediate soname bumping issue.
>>     
>
> I am aware of the fact that you have raised the problem some time
> ago and also proposed a solution and provided patches. I am also
> aware of the fact that Tridge basically turned your proposal down
> or at least the discussion stopped rather suddenly.
>   

Yes. Tridge said he couldn't see that it made any difference because he
had one test case where externally it appeared to behave the same as
behaviour without the patch.

>   
>> [I predict that someone will now talk about this rather than about the
>> actual value of the suggested fix]
>>     
>
> I still think that the value of having reference counting in
> talloc is questionable.
>
> But when we want talloc to offer reference counting, it should
> not put extra burden onto the users (programmers). This means
> that the user should not need to carry any extra knowledge about
> the inner workins around and should not need to check any other
> potential users of a given allocation context in order to
> determine which kind of free should be used. 

Precisely, and my patch makes it more like this than before.

However talloc offers reference tracking and reference counting.

If you just want reference counting, then talloc_reference(NULL, object)
and talloc_unlink(NULL, object) will add and remove a reference "count".

If you want to use reference tracking then you have to remove the
specific reference that you added.

> My naive idea is
> that it should always be safe to use talloc_free on a context,
> no matter if it is an originally allocated context or a
> reference. 
precisely. It is not so with or without tridges patch.

But "safe" doesn't mean it works. If two tracked references have been
made against an object, you can call talloc_free all you like and it
won't make any difference - if it did it would leave dangling pointers
to whoever took the reference. The actual free won't occur until the
references go away.

If you want to be able to keep calling free and have the object go away
while referenced, then they would have to be weak references which I
posted an implementation of recently in responses to one of Ronnie's posts.

> The last free-er really frees.
>
>   

precisely, except talloc_free is no longer the only mechanism to free.

In the olden days "talloc_free" meant "free". Now it means "free when
the other references have all gone away because we don't want dangling
pointers" (the point of references is to prevent dangling pointers to
free memory)

> I think this is exactly the opposit to your solution.
>   

I think it is pretty much what the talloc API promises and what my
solution fixes

> This is what I would wish for quite naively from a caller's
> perspective. It might well be that I am ignoring intrinsic
> problems here. I have to look at the previous discussions,
> at the talloc code and at your patches more thoroughly to
> give a more detailed and possibly more qualified answer.
> (And I will...)
>
> But this is as much as I can say now.
>   

I appreciate your continued attention, busy as you are.

I also want a sane talloc from a users point of view.

Sam