maria-developers team mailing list archive

[Sergei Golubchik <serg@xxxxxxxxxxx>]

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