Adding to that, we might need have to look into this: - getting the TSEventThread from a vconn, txn, ssn instead of implicitly trusting that the current thread is relevant? - moving a client vconn to a certain thread (we've seen that the thread jumping in plugins can really kill performance with pooled client-server vconns), we ended up pooling vconns per thread for the fastcgi plugin, which could be a waste and not even possible for some fastcgi servers (more threads running in TS than connections allowed to the fastcgi server) - check the callback continuations in the current API? do we want to have guaranteed callbacks on the same thread or do we want the plugin to handle this? - getting the TSEventThread of a TSThread - some documentation for plugins regarding thread alignment
Naming: TSEventThreadSelf() in line with the current API? Another advantage of scheduling a unit of work on the same thread is that we can escape some locks which are on the stack due to the recursive nature of some handling in ATS, only requesting relevant locks. This reduces the chances of deadlock or retrying. I know people doing coordination between txns will love this. A problem with this approach is that it is not always clear to developers what the relevant locks are, resulting in very interesting situations (TM) :) I remember talking with Alan and Jason about the thread aligned scheduling, and there were some concerns about possible starvation, but if core already goes out of its way to align per thread it makes sense to follow that in plugin land. What are the thoughts about this now? @Otto: We used the TSThread, but using a TSEventThread type will enhance readability and protect the developer, the implementation will be the same. On 16 August 2018 at 06:18, Alan Carroll <solidwallofc...@oath.com.invalid> wrote: > In the core, when a continuation is scheduled on a specific thread that is > not the current thread, it's because there is a locked object with the lock > held on another thread, and the goal is to have the continuation run on > that thread. This can help gather interacting objects on the same thread > where they won't have lock contention (because if I try to get a mutex > that's locked on *this* thread, it is successful). >
