talloc issues

[Stefan (metze) Metzmacher]

simo schrieb:
> On Fri, 2009-07-24 at 14:41 +1000, tridge at samba.org wrote:
>> Hi Simo, Sam and Metze,
>>
>> I've been looking over the talloc discussions to try to come to some
>> conclusions.
>>
>> First off, I'd like to apologise to Simo for my choice of words in
>> some of my messages. Some of my language was inappropriate for a
>> technical discussion.
> 
> Apologies accepted.
> 
>> Regarding Sam's patches, I still have some of the same concerns that I
>> posted last time. I think that Sam's changes make the situation
>> unambiguous only in the same sense that the old talloc code was
>> unambiguous. The old talloc behaviour was completely deterministic
>> from a strictly algorithmic sense, in that a talloc_free() on a
>> pointer with references would remove the most recent reference
>> first. Sam's patches are similarly unambiguous, in that it removes the
>> original parent first.
> 
> I think the essence of Sam's proposal, once corrected a bit from the
> original form, is that references do not influence "normal"/"expected"
> talloc behavior. IMHO this is extremely important.
> 
>> The ambiguity that I am trying to resolve comes not from a strictly
>> deterministic/non-deterministic sense of the word, but from the fact
>> that a programmer working in one module cannot with any degree of
>> certainty predict what will happen without full knowledge of what is
>> happening elsewhere. I think that is still true with Sam's proposed
>> changes.
> 
> I think the only thing that is still a bit less deterministic is what
> happen to destructors. Without references you are always sure that if
> you free a talloc hierarchy all memory gets freed and all destructors
> are fired. With references it may happen that some memory is kept alive
> instead and destructors are delayed. But this is the same in both
> solutions, so I wouldn't base my choice on one or the other, based on
> this point.
> 
>> I also think that the way that talloc_steal() can become a function
>> that effectively changes the reference count is also a big concern,
>> and not something I think we want.
> 
> I totally agree that making talloc_steal() "special", in this sense, is
> not useful at all, it is actually rather dangerous.
> I think this is something that the original Sam's proposal got wrong
> indeed.
> 
> Metze and I have discussed a bit what would be appropriate behavior for
> talloc_free() and talloc_steal() after you take a reference. I think the
> conclusion was (Metze correct me if I got something wrong) that 
> 
> A) once talloc_free() is called, any other talloc_free() or
> talloc_steal() on the same talloc context should fail with a double free
> error. Exactly like it would happen if there were no references.
> 
> B) the code using talloc_reference() must use talloc_reparent() and
> talloc_unreference(). You cannot use talloc_free() or talloc_steal(),
> they do not affect references. The code using the references is aware of
> the fact you used them so it shouldn't be difficult to stick with this
> rule.
> 
> Of course freeing a parent context frees also the references it may
> hold, nothing changes there.
> 
> (Btw I would rename talloc_reparent() to talloc_rereference() in this
> case and make it operate exclusively on references).
> 
> I think that this way you can safely use talloc the "normal" way in the
> original code and live issues, if any, only on the shoulders of who
> decides to use talloc_reference() without influencing code practices of
> the original context owner.
> 
> This is what I call the Sam's modified/corrected proposal.


I have some code here:
http://gitweb.samba.org/?p=metze/samba/wip.git;a=shortlog;h=refs/heads/master4-talloc-metze

I'll reply more verbose tomorrow or next week.

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/20090724/f5c17fc5/attachment.pgp>