Yes, definitely +1 on the idea!
Curious though, why couldn't we just ditch the existing ConnArg / SsnArg /
TxnArg, in favor of the GlobalArgs or may be even just replace the existing
ArgTable with the vector?
-- Sudheer
On Thursday, February 27, 2020, 09:13:11 AM PST, Leif Hedstrom
<[email protected]> 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
