Hi,
Thank you for the updated patch.
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?
IIUC, this introduced an overhead of one dsm_create call for every
dsa_create or dshash_create
call.
> I don't know if it's better to manage 3 dshash tables than to manage 1 with
> special entries for DSAs/dshash tables.
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.
-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.
+
+ entry->val = dsa_allocate(tdr_dsa, strlen(val) + 1);
>
> One other thing we could do is add a dsa_is_attached() function and then
> ERROR if you try to reattach an already-attached DSA/dshash. I've done
> this in the attached patch.
>
Sounds good. Not a problem of this patch but it would be great if
we had dsa equivalent of dsm_find_mapping that could actually return a
backend
local reference of the dsa_area.
Thank you,
Rahila Syed
