[DTrace-devel] [PATCH 4/7] htab: add dt_htab_purge to purge an htab rapidly

[Nick Alcock]

On 11 Oct 2021, Eugene Loh stated:

> I suppose my comments here are redundant with what I said elsewhere, but 
> for completeness I'll comment on this patch.  I've not thought this 
> through 100%, but how about the function concludes with a 
> dt_htab_destroy(dtp, htab) call?  And, add a destructor callback 
> function to htabs so that htabs can be destroyed more often with just a 
> call to this function rather than having to maintain separate lists (in 
> addition to the htab) for the single purpose of being able to iterate 
> over the entries for destruction?  (I'm just rehashing what I said on 
> the other patches.)

For this particular case, not all of this is practical.  We must
maintain a dt_modlist because the ordering of modules matters: we need
to iterate over them in insertion order, or e.g. the C and D modules and
vmlinux won't be likely to come first.

So for this one I've tried a different approach: a dtp backpointer in
the module so the destructor can get at the dt_modlist to purge entries
from it.

Let's see which of these (the iterator, or the backpointer) is nicer to
work with :) honestly I think this is probably the right thing to do
with the provider too (and if you agree I'll transplant the old provider
commit back in and adjust it)... though the htab iteration support is
nice and I do hope to keep it as well.

> On 10/5/21 9:38 AM, Nick Alcock wrote:
>> Destroying large htabs right before destroying their contents is
>> annoying: you have to delete every entry one by one from the htab before
>> you destroy it, lest you leak all the buckets: this also serves to reset
>> the dt_hentry pointers in every entry.
> How about a more specific adjective in place of "annoying."  Also, 
> replace the colons with full stops.

I dunno, it seemed pretty specific to me. It annoyed me to have to do
this sort of thing by hand or risk memory corruption at an unknown later
date.

-- 
NULL && (void)