"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?
