Thread

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

    Florents Tselai <florents.tselai@gmail.com> — 2025-06-11T16:08:25Z

    
    > On 11 Jun 2025, at 5:23 PM, Nathan Bossart <nathandbossart@gmail.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@gmail.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 :)