the sorry saga of the talloc soname 'fix'

[Kai Blin]

On Wednesday 08 July 2009 11:30:56 Sam Liddicott wrote:

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

I have to admit that I don't understand your proposed solution. I have only 
been skimming this (and related) discussions as I've got more important 
things on my agenda, but to quote from your recent post on the subject:

-----8<------
Before I explain, some points must be acknowledged:

   1. There exists much code that uses talloc_steal/talloc_free
      ambiguously.
   2. This code needs fixing anyway.
   3. It is being fixed with the aid of tridge's patch
-----8<------

I'm happy to acknowledge this, but it is my understanding that the ambiguity 
comes from mixing talloc_reference and the two "culprits".

-----8<------
Before I explain, these points must be understood:

   1. talloc_reference, talloc_reparent, talloc_unlink are pure and holy
      and have zero ambiguity
   2. talloc_steal and talloc_free are said to be ambiguous (herein lies
      the entire problem).
-----8<------

I read this, but as mentioned above I'm not quite sure I understand. This was 
the point where I decided that given I don't fulfill the invariants you set 
for reading the explanation, reading it is not really that useful.

[...]

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

Sorry, but that's not helpful. I was wondering about the same thing as Michael 
here, and I could even claim I'm a Samba4 developer. I've never run into a 
problem where the obvious solution to my problem was using references. 
Also, "Trust me, I know what I'm talking about" is not very convincing. I'd 
trust the senior devs to know what they're talking about, but recent evidence 
shows that the trouble is that everybody seems to be talking about different, 
contradicting things. An example would help to clarify for people like me, 
who don't even fully see what is being talked about.

I've looked at the patches you posted, and none of the test cases answers 
Michael's question about a use case for talloc_reference. So for me all that 
the fact that you've written the patches AND test cases AND tried for 8 
months to have someone pay attention to this enough tells me is that you 
really care about talloc_reference semantics. From the tone of your email I 
also seem to be some kind of idiot to not care about it.

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

Not at all. We're just curious what this would be used for. If it's so 
complicated that only reading all of your code can illustrate it, then I've 
got to admit that I don't care enough. As I've mentioned before, I've got 
other things to work on as well. If your use case is very complicated and 
there is no easy example, please stop being condescending to people who don't 
immediately understand what you're talking about.

Given that I've happily used talloc without ever having to learn about 
talloc_reference tells me that it's probably a pretty advanced feature, which 
just judging from the constant discussions on using it is very hard to use 
correctly. It now seems to me that in order to understand why the calls to 
talloc_steal and talloc_free I've used so far are likely to be wrong, because 
talloc_steal and talloc_free are bad. However, it seems impossible for me to 
tell if my specific use of those calls is bad because I need to wrap my head 
around a more complicated model of talloc first. Personally I think if you 
need to spend two weeks to learn talloc before being able to start working on 
Samba tells me the memory allocation library is too complicated.


> [I predict that someone will now talk about this rather than about the
> actual value of the suggested fix]

There, now I'm annoyed in addition to confused because you've made it 
impossible to respond to email without looking even more silly.
Kai
-- 
Kai Blin
WorldForge developer  http://www.worldforge.org/
Wine developer        http://wiki.winehq.org/KaiBlin
Samba team member     http://www.samba.org/samba/team/
--
Will code for cotton.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
Url : http://lists.samba.org/archive/samba-technical/attachments/20090709/69c08d94/attachment.bin