Closed
Bug 1372333
Opened 7 years ago
Closed 4 years ago
Consider adding a Remove method on nsBaseHashtable::EntryPtr
Categories
(Core :: XPCOM, enhancement, P3)
Core
XPCOM
Tracking
()
RESOLVED
FIXED
People
(Reporter: MatsPalmgren_bugz, Unassigned)
References
Details
Consider adding a Remove method on nsBaseHashtable::EntryPtr (added in bug 1371094).
This is for cases where LookupForAdd is preferable over Get+Put for performance,
but we have some exceptional cases (errors or reaching a max entry count, etc)
where one needs to remove the speculatively added entry.
One could also imagine having a auto-Remove feature such that if OrInsert
is never called on a newly added entry, it is auto-Removed in the dtor.
Example:
auto entry = hashtable.LookupForAdd(key);
if (entry) {
// OK, it existed already
} else {
entry.AutoRemoveIfNotAssigned();
// complex code to initialize the new value here...
if (NS_FAILED(rv)) {
return;
// the new entry is Remove'd by the dtor since we never reached OrInsert
}
entry.OrInsert([&value](){ return value; });
}
Reporter | ||
Updated•7 years ago
|
Severity: normal → enhancement
OS: Unspecified → All
Hardware: Unspecified → All
Updated•7 years ago
|
Priority: -- → P3
Comment 1•4 years ago
|
||
LookupForAdd
and EntryPtr
do no longer exist. WithEntryHandle
provides an EntryHandle
that has Remove/OrRemove
methods. (I think that has already been true for EntryPtr
recently).
WithEntryHandle
also implements the "auto-remove" behaviour suggested: It only tentatively reserves an entry, but does not construct it until (Or)Insert
is called.
Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•