>> If the memory returned by these new functions are not in the Txn arena, >> where are they stored?
In a swoc::MemArena which will replace the Arena in the HTTP state machine. >> 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? Arena based memory is also much faster to allocate and de-allocate. This is particularly true for strings, contrasting arena memory vs. Std::string. I also consider this effectively zero over head because the HttpSM needs an arena for its own purposes. With the better API provided by swoc::MemArena it becomes useful to also expose it to plugins. Also, in addition to the TSCont, that consumes a more precious resource, a user transaction argument. This work is intended for data that does not require cleanup, strings and PODs. It might be reasonable to unify these be replacing / implementing Finalizers using the aux data manager. From my point of view, finalizers are exceptional and rarely used. I would expect most plugins to not use them. What could be done is rather than having a class for such management, provide a utility function that allocates and constructs a type T and also arranges (using this mechanism) to do the cleanup on TXN_CLOSE. -----Original Message----- From: Walt Karas <wka...@yahooinc.com.INVALID> Sent: Thursday, December 7, 2023 9:27 AM To: dev@trafficserver.apache.org Subject: Re: [E] [TSAPI] TSTxnAlloc
