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.
On Thursday, September 18, 2025 at 07:46:23 PM EDT, Walt Karas <[email protected]> wrote: I wrote the polite_hook_wait test/example. I haven't worked on ATS in over a year, so my memory is rusty. I think the issue is, it's typically not thread safe to call many TSAPI functions from another thread (other than the one handling the API hook). So the approach using the TSMutex was needed, in order to safely set the HTTP Response Status of the transaction. It would be good, if you have time, to investigate this further. Improve the code if possible, and/or add more documentation. On Thursday, September 18, 2025 at 08:44:37 AM EDT, Valtteri Vuorikoski <[email protected]> wrote: Hi, I have been looking at writing a plugin to do some potentially-blocking authentication processing at the READ_REQUEST_HDR phase using a worker thread pool. In the example code, there seem to be three ways of resuming the ongoing transaction from a TSThreadCreate'd thread: 1. The thread_1 example just calls TSHttpTxnReenable(txnp, TS_EVENT_HTTP_CONTINUE) on the worker thread. 2. The polite_hook_wait test case arranges for the worker thread to acquire the continuation's mutex and then immediately invokes TS_EVENT_HTTP_CONTINUE at the end of the hook callback. 3. The thread_pool example arranges for a callback to be invoked with TSContScheduleOnPool when the worker finishes, and the callback resumes processing the transaction. What's the difference between these approaches, especially 1 vs. 2&3? Is one of them preferred for a use case where the worker needs to attach data to the ongoing transaction for use at later hook points (such as SEND_RESPONSE_HDR), but does not use any event-driven facilities (TSV{IO,Conn}* functions or similar)? Also, is it safe to call TSHttpTxnClientReqGet and TSMime* functions on the worker thread e.g. to get request headers? Does some other lock besides the continuation mutex need to be held? Thanks, Valtteri
