I guess my comments for the TxnAuxDataMgr class template are too sparse: https://github.com/apache/trafficserver/blob/d13e3a7c3c799c9493670fd791edf53963e00bd8/include/tscpp/api/Cleanup.h#L127
It only involves creating a single TSCont instance per plugin at startup (in the plugin init function). Is a single TSCont per plugin too much? If the memory returned by these new functions are not in the Txn arena, where are they stored? On Thu, Dec 7, 2023 at 9:56 AM Alan Carroll <a...@network-geographics.com> wrote: > "Arena.h" is scheduled for KIWF. This would be implemented using > swoc::MemArena, which is already available to plugins. I am concerned about > giving plugins direct access to the MemArena because I planned to use it > internally in the HttpSM as well. I would be interested to > hear what others thinks about exposing the MemArena. > > Internally the finalizers are implemented as an IntrusiveDList in the > MemArena, which avoids having to create and cleanup TSInkCont instances. > Also I want to avoid calling any plugin API (such as TSXXXDestroy) to avoid > reliance on the HttpSM being in a usable state. And the finalizers are > about cleaning up UDTs, not ATS resources. > > -----Original Message----- > From: Walt Karas <wka...@yahooinc.com.INVALID> > Sent: Wednesday, December 6, 2023 9:25 PM > To: dev@trafficserver.apache.org > Subject: Re: [E] [TSAPI] TSTxnAlloc > > Could we move Arena.h to tscpp/util, and just add: > > Arena & tsapi::txnArena(TSHttpTxn txn); > > For your finalizer example, when would that be better than using > Cleanup.h? That is, when would it be better than having the vector be a > data member of the TxnAuxData class you provide as a parameter to the > TxnAuxDataMgr template? >
