John Dennis wrote: > On 12/08/2009 12:35 PM, Dmitri Pal wrote: > >> Simo Sorce wrote: >> >>> On Mon, 2009-12-07 at 09:51 -0500, Dmitri Pal wrote: >>> >>> >>>> 0002 - Dhash improvement. See patch comments. (independent patch) >>>> >>>> >>> I am leaning on nacking this one. >>> It is redundant and basically just duplicates code. >>> >>> The only difference between hash_lookup+hash_delete and hash_remove is >>> one less lookup, if that's the point one can simply modify hash_delete >>> to return the value, or not modify anything and use the delete_callback. >>> >>> Duplicating code is not the best way. >>> >>> Simo. >>> >>> >>> >> Yes I looked at this one and was concerned with the same thing but I >> could not find a way to make less duplication of the code. >> I did not want to modify the existing function since I did not want to >> go hunting all the places where it might be used. >> But I also was concerned about the duplication as you are and tried to >> fund a way to use a common function internally for the two or one wrap >> another but I ended up doing what I did since I did not find a better >> way of doing things. May be I am missing something. >> > > I think Simo's suggestion of using the delete callback in these cases is > the best idea. If you allow returning values from the delete operation > you have the potential for inconsistencies. How do you know if value > returned is still valid after the delete? It might have been freed by > the delete callback. No API changes are necessary and no performance > impacts are encountered if you just use the callback mechanism. > > > Callback misses the parameter for this to work so that one can determine in the callback the condition when the callback is invoked "the delete operation" vs "destroy table". I need this difference so I hope that this will be added to the callback.
-- Thank you, Dmitri Pal Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ _______________________________________________ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/sssd-devel