![](https://secure.gravatar.com/avatar/39b623a1559cf9c69ac3d9d4fb44e7fe.jpg?s=120&d=mm&r=g)
Hi, Sergey! On Dec 04, Sergey Vojtovich wrote:
"SHOW VARIABLES" looks correct. So I have only two ideas: - Fix INSTALL PLUGIN so it releases LOCK_plugin before registering variables. Sounds like the best solution, but there are a few more things to fix, e.g. UNINTALL PLUGIN.
Is it possible? On a quick look I wasn't able to answer that :(
It should be quite easy: for INSTALL PLUGIN we just move test_plugin_options() to plugin_initialize() while plugin state is PLUGIN_IS_UNINITIALIZED. Same for UNINSTALL PLUGIN.
Okay. Looks like it'll work.
Here's yet another idea: don't protect plugin->ref_cnt and plugin->state with LOCK_plugin. Then intern_plugin_lock and intern_plugin_unlock could be completely lock-free. One would need to increment ref_cnt before or at the same time as checking the state. It *seems* that the rest of the code could support that with very few changes. But it'd need more analysys.
Well, lock-free ref_count is not a problem. Lock-free state is challenging, but looks doable. What about reap_plugins() which is called by plugin_unlock()?
reap_plugins() would need a lock, of course. No lock for intern_plugin_unlock() means that it might mark reap_needed=true, but before the plugin is reaped, another thread might lock it again and reap_plugins() will do nothing. Not a big deal. Still, there're race conditions around intern_plugin_lock() - when a plugin gets uninstalled and a new plugin is installed and intern_plugin_lock() doesn't notice it. I *think* we can solve all that, looks doable, indeed. But I'd rather prefer a simple solution now, if you can move test_plugin_options() as you want to. We can do lockless plugin reference counting later, when LOCK_plugin will be a performance bottleneck. Regards, Sergei