On Tue, Dec 12, 2023 at 1:03 PM Alan Carroll <a...@network-geographics.com> wrote:
> >> 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://urldefense.com/v3/__https://github.com/apache/trafficserver/blob/d13e3a7c3c799c9493670fd791edf53963e00bd8/include/tscpp/api/Cleanup.h*L127__;Iw!!Op6eflyXZCqGR5I!EcptkopTLq_jA58Pq4lCnio8yangZqNiz9gVZy7QoUIVxKwqQYR_V_8VoJQXgJM9Abf3VOjT1XdGJMfg0P_E$ > > >> 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.\ > I don't see how your answers are related to my questions so I'll let others consider this. > -----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 > > >
