> On 10 Jun 2025, at 7:21 PM, Nathan Bossart <nathandboss...@gmail.com> wrote: > > On Tue, Jun 10, 2025 at 10:38:29AM -0500, Nathan Bossart wrote: >> On Mon, Jun 09, 2025 at 07:14:28PM -0500, Sami Imseih wrote: >>> Going back to the original point, DSMRegistryHash and DSMRegistryHash >>> are built-in, and those names are well-defined and actually refer to >>> waits related to the mechanism of registering a DSA or a HASH. >>> I think it will be odd to append "_dsh", but we should at minimum add >>> a comment in the GetNamedDSMHash explaining this. >> >> This should be addressed in v3. >> >> I'm not quite following your uneasiness with the tranche names. For the >> dshash table, we'll need a tranche for the DSA and one for the hash table, >> so presumably any wait events for those locks should be named accordingly, >> right? > > Unrelated, but it'd probably be a good idea to make sure the segment is > initialized instead of assuming it'll be zeroed out (and further assuming > that DSHASH_HANDLE_INVALID is 0)... > > -- > nathan > <v4-0001-simplify-creating-hash-table-in-dsm-registry.patch>
Love this new API. Two minor things a minor typo here + * current backend. This function gurantees that only one backend Since you made the first step towards decoupling DSMR_NAME_LEN from NAMEDATALEN; is it worth considering increasing this to 128 maybe? I’ve used DSMR extensively for namespacing keys etc, and I’ve come close to 50-60 chars at times. I’m not too fixed on that though.
