the sorry saga of the talloc soname 'fix'

[Michael Adam]

Sam Liddicott wrote:
> * Michael Adam wrote, On 08/07/09 10:17:
> > Sam Liddicott wrote:
> >   
> >> * Michael Adam wrote, On 08/07/09 09:42:
> >>     
> >>> The remedy for all our problems is to just get rid of
> >>> talloc_reference/talloc_unreference, the source of all
> >>> evil and grief.
> >>>
> >>> Frankly, I personally can't imagine why one would use them at all...
> >>>   
> >>>       
> >> Excellent a joke!
> >
> > In fact, I am not joking. :-)
> >
> > talloc_(un)reference turns the neat, simple tree of memory
> > allocations into a graph with cycles and whatnot. This is
> > the origin of the problems we are currently discussing.
> >
> > And I really think that this additional complexity is avoidable.
> >   
> The additional complexity can be managed quite simply (won't someone
> please ready my solution instead of just arguing about whether or not
> there is a real problem). We can even solve the cycles problem, I have
> talked about it, but if no-one will read this solution there's no point
> in talking about the solution to the cycles.
> > Maybe this is due to the fact that I have up to now mainly worked
> > on the samba3 codebase where there is virtually no use of
> > talloc_reference, as opposed to samba4 which makes rather heavy
> > use of talloc_reference. I myself have never used it and I have
> > never felt the need to do so.
> >
> > And given the problems that this creates, I really cannot see
> > why one would not try to avoid using talloc_reference by all
> > means (only because of sheer laziness.. ;-).
> >   
> 
> Of course you can't see why, because as you say you don't use it.
> 
> > Sam, please excuse my ignorance, can you give me an example of a
> > situation that you could not have solved without talloc_reference?
> >   
> Isn't the fact that I've debugged the problem, the fact that I've
> written the patches AND the test cases AND tried for around 8 months to
> have someone pay attention to this enough for you to take me seriously?

Sam, I am taking you 100% seriously!

But because I have not really been concerned with the
talloc_reference problem yet, I had not tightly followed the
discussion earlier.

> Now, rather than have the fix reviewed, I'm to have a critical review of
> my code by people who don't use or need to use talloc_reference to see
> if I could possibly have worked around this feature that the talloc API
> offers?

Hey, I am not questioning _your_ use of talloc_reference
especially, but any use.

> 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.

> [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. 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. The last free-er really frees.

I think this is exactly the opposit to your solution.
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.

Cheers - Michael

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 206 bytes
Desc: not available
Url : http://lists.samba.org/archive/samba-technical/attachments/20090709/f2b26d94/attachment.bin