I understand your goal but I think this is the wrong approach. I think it would work better to add names to the "config" in the TSConfigGet family of functions. This also provides a nice "check out/in" mechanism for synchronization,
On Thu, Feb 27, 2020 at 11:13 AM Leif Hedstrom <zw...@apache.org> wrote: > Hi all, > > This is an idea from Bryan Call, which he suggested as a solution for > reloadable plugins changes that are now in 9.0.x. I recently ran into a > different use case (thanks Miles …), which could really benefit > (performance wise) with such APIs. I *could* use the TxnArg APIs instead, > but these new global arg APIs would make it noticeable faster (and less > locking). So, I’m writing up this proposal based on these ideas, for > discussion / adjustments. > > First off, I’m modeling these completely after the existing ConnArg / > SsnArg / TxnArg, with the exception that they won’t have a limit on the > number of slots (why bother?). > > TSReturnCode TSGlobalArgIndexReserve(const char * name, const char * > description, int * arg_idx) > TSReturnCode TSGlobalArgIndexNameLookup(const char * name, int * > arg__idx, const char ** description) > TSReturnCode TSGlobalArgIndexLookup(int arg_idx, const char ** name, > const char ** description) > void TSGlobalArgSet(TSHttpTxn txnp, int arg_idx, void * arg) > void * TSGlobalArgGet(TSHttpTxn txnp, int arg_idx) > > I’m thinking a simple std::vector here (with a lock for good measure) for > reserving and looking up slots by name. As for lookup performance, I don’t > think this is a problem though, I imagine the use case here is to call > TSGlobalArgIndexReserve() and TSGlobalArgIndexNameLookup() in the Init() > functions of plugins that need access to a global slot, and from thereon > use the index only. The vector will simply store a void*, the name and > description. > > And discuss. > > — Leif > >
