I suggest you think through whether you have all the necessary memory fences. It may be we've just been lucky in the past, running on the x86 with it's strongly ordered memory model. With that (and no LTO with link-time inlining), you effectively get an acquire/release fence every time you call a function outside the compilation unit.
On Friday, September 19, 2025 at 05:16:37 PM EDT, Walt Karas <[email protected]> wrote: 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
