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

> On 11 Jun 2025, at 5:23 PM, Nathan Bossart <nathandbossart(at)gmail(dot)com> wrote:
>
> On Wed, Jun 11, 2025 at 05:11:54PM +0300, Florents Tselai wrote:
>>> On 11 Jun 2025, at 4:57 PM, Nathan Bossart <nathandbossart(at)gmail(dot)com> wrote:
>>> I considered adding another function that would create/attach a DSA in the
>>> DSM registry, since that's already an intermediate step of dshash creation.
>>> We could then use that function to generate the DSA in GetNamedDSMHash().
>>> Would that work for your use-cases, or do you really need to use the same
>>> DSA as the dshash table for some reason?
>>
>> In my case the hashtable itself stores dsa_pointers (obviously stuff
>> allocated in the dsa as the hash table itself) so I think I can’t avoid
>> the necessity of having it.
>
> Is there any reason these DSA pointers can't be for a separate DSA than
> what the dshash table is using?

I guess not. You’re right I can decouple them.

>
>> Unless, you see a good reason not to expose it ?
>
> I'm not sure there's any real technical reason, but I guess it feels
> cleaner to me to keep the DSM-registry-managed dshash DSAs internal to the
> implementation. Presumably messing with that DSA introduces some risk of
> breakage, and it could make it more difficult to change implementation
> details for the named dshash code in the future.

You convinced me there :)