I'm not on the project anymore, so I shouldn't participate in any decisions. The polite_hook_wait design might be useful (to reduce transaction latency) if the transaction-specific continuation was put on a later hook, rather than the current one.
Yes, if you can do what you need to do with non-blocking/asynchronous operations, that will avoid the need for dynamically creating a thread (or getting a thread from a pool). On Friday, September 19, 2025 at 04:05:36 PM EDT, Valtteri Vuorikoski <[email protected]> wrote: On Fri, Sep 19, 2025 at 01:43:00AM +0000, Walt Karas wrote: > In the thread_1 example, I guess it should be safe to call TS API functions > that access HttpSM object, if it's done before the TxnReenable() call. Looking > at the code for HttpSM::state_api_callout(), it doesn't handle a locked plugin > continuation mutex in a smart way. It just blocks on it, rather than executing > unblocked plugin continuations, and coming back to the blocked ones. Which > means you may or may not get any "politeness", depending on where the > continuation is in the list. So, it may be better to keep things simple, and > not use the polite_hook_wait approach. Ok, if the polite_hook_wait code doesn't work as expected, should it still be kept in the test suite? The HttpSM/HttpTransact machinery is so complex that I can't really make much of it directly. However, the code for TxnReenable looks like it will automatically schedule the state change on an ET_NET thread if called in a non-EThread context. So it sounds to me like case 1 (thread_1/call TxnReenable on the worker thread) should work if the plugin doesn't need any async IO, but case 3 (thread_pool/schedule callback to continuation handler) should be used if TS(V)IO* or similar are needed (probably mostly relevant to transform plugins?). -Valtteri
