Closed Bug 1209351 Opened 10 years ago Closed 10 years ago

Add to nsTHashTable the ability to remove an already-found entry

Categories

(Core :: XPCOM, defect)

defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla44
Tracking Status
firefox44 --- fixed

People

(Reporter: n.nethercote, Assigned: n.nethercote)

References

Details

Attachments

(6 files)

This is a follow-up to bug 1202526, which did the same thing for PLDHashTable. Here are two common nsTHashTable usage patterns: > Entry* entry = table.GetEntry(key); > if (!entry) { > return NS_ERROR_BLAH; > } > table.RemoveEntry(key); > Entry* entry = table.GetEntry(key); > if (foo(entry)) { > table.RemoveEntry(key); > } In both cases RemoveEntry() does an unnecessary re-lookup. You could instead use RawRemoveEntry(), but it does not subsequently shrink the table if its capacity gets too low. This bug is about adding a new function that takes an already found entry (like RawRemoveEntry()) but also shrinks the table afterwards if appropriate (like RemoveEntry()).
Attachment #8667028 - Flags: review?(jmuizelaar) → review+
Attachment #8667038 - Flags: review?(mcmanus) → review?(michal.novotny)
Attachment #8667040 - Flags: review?(dkeeler) → review+
Attachment #8667026 - Flags: review?(nfroyd) → review+
Attachment #8667041 - Flags: review?(nfroyd) → review+
When reviewing the toolkit/ patch, I realized one (small) problem is that people might do something like: Entry* e = mTable.GetEntry(x); if (e) { // ... mTable.RemoveEntry(e); ... // do something with e, which points to something completely different } It looks like e will have been destroyed, which may or may not leave it in a state that is sensible, but mTable could also have been resized, which means e may also point to a valid entry...just not the entry we thought it did. WDYT about making RemoveEntry taking an |Entry*&|, so we can null out the pointer from the hashtable code? (Maybe as a followup bug?) That way, people mistakenly using Entry* after removing it would get a loud error about it (a null pointer dereference), rather than things happening to work and then not... I guess RemoveEntry should also have documentation stating that you're not supposed to use the entry after it has been removed, too.
Flags: needinfo?(n.nethercote)
> WDYT about making RemoveEntry taking an |Entry*&|, so we can null out the > pointer from the hashtable code? Not a bad idea...
Flags: needinfo?(n.nethercote)
Comment on attachment 8667027 [details] [diff] [review] (part 2) - Optimize nsTHashTable::RemoveEntry() usage in dom/ r=me
Attachment #8667027 - Flags: review?(bzbarsky) → review+
Attachment #8667038 - Flags: review?(michal.novotny) → review+
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: