Re: add function for creating/attaching hash table in DSM registry

On Tue, Jun 17, 2025 at 05:43:24PM +0530, Rahila Syed wrote:
>> Using a DSA from the registry is cumbersome. You essentially need
>> another batch of shared memory to keep track of the pointers and do
>> locking, so it might not be tremendously useful on its own
>
> Isn't this true while using dshash from the registry as well?

No, once you have a pointer to the dshash table, you should be able to
access it without any other special runtime-generated pointers.

> What if we make the DSM registry hash table generic so it can be used for
> dsm segments, dsas as well as dshashs?
>
> The DSMRegistryEntry could be modified as follows to contain a dsa_pointer
> instead of actual values.
> typedef struct DSMRegistryEntry
> {
> char name[64];
> dsa_pointer value;
> } DSMRegistryEntry;
>
> This dsa_pointer could point to a memory chunk in the same dsa that's
> created by init_dsm_registry to store the Dshash registry table.
>
> This pointer can be cast to a structure pointer with information about
> DSMs, DSAs, or DSHASHs, based on which one we want to register in the
> registry.

I like this idea, but I took it one step further in the attached patch and
made the registry entry struct flexible enough to store any type of entry.
Specifically, I've added a new "type" enum followed by a union of the
different structs used to store the entry data. I was originally trying to
avoid this kind of invasive change, but it's not nearly as complicated as I
feared, and there are benefits such as fewer shared memory things to juggle
and better sanity checking. It should also be easy to extend in the
future. WDYT?

> -static TestDSMRegistryStruct *tdr_state;
> +typedef struct TestDSMRegistryHashEntry
> +{
> + char key[64];
> + dsa_handle val;
> +} TestDSMRegistryHashEntry;
>
> Did you mean to create val as dsa_pointer instead of dsa_handle?
> You assigned it a dsa_pointer in set_val_in_hash() function.

Yes, good catch.

--
nathan