Yeah, I misunderstood the use case and the proposal. Synced up with Leif offline and I understand it better now. The existing Txn API allows to share data across states within a given transaction, while the new API is to share data globally across transactions.
I’m still +1 on the new API, of course, as I think this is really simple to implement and definitely very useful to share global data in a consistent (and supported) manner than having to rely on something undocumented (like we do for sharing global data between global and remap plugins) which as it’s proven now is susceptibility to changes. And yes, I think you are right about not using the Txn param in the GlobalArg Set/Get API. That seemed like a typo. > On Feb 27, 2020, at 1:32 PM, Walt Karas <wka...@verizonmedia.com.invalid> > wrote: > > Sudheer, can you create a branch in your trafficserver fork, that switches > an existing plugin from using TxnArg to GlobalArg? I don't see how that > would work typically. I believe the point is that you want a different > value for the same arg index for each transaction. > >> On Thu, Feb 27, 2020 at 11:40 AM Sudheer Vinukonda >> <sudheervinuko...@yahoo.com.invalid> wrote: >> >> 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 < >> 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 >>
