Commit 700e2155 authored by Sergei Golubchik's avatar Sergei Golubchik

do not take LOCK_plugin for built-in plugins

parent f0cf48a0
......@@ -622,7 +622,10 @@ static plugin_ref intern_plugin_lock(LEX *lex, plugin_ref rc CALLER_INFO_PROTO)
{
plugin_ref plugin;
#ifdef DBUG_OFF
/* built-in plugins don't need ref counting */
/*
In optimized builds we don't do reference counting for built-in
(plugin->plugin_dl == 0) plugins.
*/
if (!pi->plugin_dl)
DBUG_RETURN(pi);
......@@ -655,6 +658,26 @@ plugin_ref plugin_lock(THD *thd, plugin_ref ptr CALLER_INFO_PROTO)
LEX *lex= thd ? thd->lex : 0;
plugin_ref rc;
DBUG_ENTER("plugin_lock");
#ifdef DBUG_OFF
/*
In optimized builds we don't do reference counting for built-in
(plugin->plugin_dl == 0) plugins.
Note that we access plugin->plugin_dl outside of LOCK_plugin, and for
dynamic plugins a 'plugin' could correspond to plugin that was unloaded
meanwhile! But because st_plugin_int is always allocated on
plugin_mem_root, the pointer can never be invalid - the memory is never
freed.
Of course, the memory that 'plugin' points to can be overwritten by
another plugin being loaded, but plugin->plugin_dl can never change
from zero to non-zero or vice versa.
That is, it's always safe to check for plugin->plugin_dl==0 even
without a mutex.
*/
if (! plugin_dlib(ptr))
DBUG_RETURN(ptr);
#endif
pthread_mutex_lock(&LOCK_plugin);
rc= my_intern_plugin_lock_ci(lex, ptr);
pthread_mutex_unlock(&LOCK_plugin);
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment