You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In many occasions we could be in the situation where the key we are trying to insert is already in the map. We often need to do a bit different processing (different response, update timestamp, etc.) for that case, hence currently we are doing a lot of query-check-insert, which would do map lookup twice.
This commits adds a insert_maybe_exist interface the either return the existing map entry or insert a new one, and communication about which case it is to the caller.
Does fd_map_slot.c upsert already cover this case? ``` // mymap_upsert:
//
// ... join is a current local join and key points to the key of
// ... interest (for maps that use key sentinels, *key should not
// ... be a sentinel key), retains no interest in join or key.
//
// ele = mymap_upsert( join, key );
//
// if( FD_UNLIKELY( !ele ) ) {
//
// ... element *key is not in map and the map is too full to
// ... insert it
//
// } else if( FD_UNLIKELY( mymap_ele_is_free( ele ) ) ) {
//
// ... element *key was not in map and should be inserted at
// ... ele. See insert for details how to complete inserting
// ... ele.
//
// ... Note that if mymap uses key sentinels to indicate when
// ... an element is free, this code path will never be taken.
// ... That is, the caller will not be able to tell via
// ... mymap_ele_is_free if an upsert is inserting or updating
// ... as the upsert initialized ele's key field (implicitly
// ... marking the element as not free such).
//
// } else {
//
// ... element *key is stored in the map at ele. See update
// ... for details how to complete updating ele.
//
// ... Note that if mymap uses key sentinels to indicate when
// ... an element is free, we might actually be inserting ele
// ... here (see note above).
//
// }
I think mostly yes. But mymap_upsert is not available in the non-slot (fd_map_dynamic) map? fd_map_dynamic also doesn't have the explicit entry-free-indicator (like mymap_ele_is_free) to make the upsert result more clear... (if it's an insert or update)
Actually I see your point now, we didn't have fd_map_slot in our FD commit...
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
In many occasions we could be in the situation where the key we are trying to insert is already in the map. We often need to do a bit different processing (different response, update timestamp, etc.) for that case, hence currently we are doing a lot of query-check-insert, which would do map lookup twice.
This commits adds a
insert_maybe_existinterface the either return the existing map entry or insert a new one, and communication about which case it is to the caller.