-
Marc Alff authored
This change is a performance tuning improvement. Before this fix, a line of code instrumented as: PSI_MUTEX_CALL(start_mutex_wait)(...); would always be compiled using a indirect call, using a function pointer: PSI_server->start_mutex_wait(...); This is expected when building code for dynamic plugins, but inefficient when building code inside the server itself. With this fix, the same line of code is now compiled as either PSI_server->start_mutex_wait(...); or pfs_start_mutex_wait_v1(...); depending of whether a dynamic or static call is needed. The net result is that instrumentation calls for the server code itself can now be compiled staticly. The server code has been adjusted to use static calls for the instrumentation interface, which affected the server initialization code. As part of this change, helper functions are defined to wrap access to thread local storage, so that detecting invalid TLS usage is easier.
Marc Alff authoredThis change is a performance tuning improvement. Before this fix, a line of code instrumented as: PSI_MUTEX_CALL(start_mutex_wait)(...); would always be compiled using a indirect call, using a function pointer: PSI_server->start_mutex_wait(...); This is expected when building code for dynamic plugins, but inefficient when building code inside the server itself. With this fix, the same line of code is now compiled as either PSI_server->start_mutex_wait(...); or pfs_start_mutex_wait_v1(...); depending of whether a dynamic or static call is needed. The net result is that instrumentation calls for the server code itself can now be compiled staticly. The server code has been adjusted to use static calls for the instrumentation interface, which affected the server initialization code. As part of this change, helper functions are defined to wrap access to thread local storage, so that detecting invalid TLS usage is easier.
Loading