Is the workaround to use static rather than dynamic plugins?
On Tue, Aug 20, 2013 at 7:31 AM, Sergei Golubchik <s...@mariadb.org> wrote: > Hi, Pavel! > > On Aug 20, Pavel Ivanov wrote: > > On Tue, Aug 20, 2013 at 1:09 AM, Sergei Golubchik <s...@mariadb.org> > wrote: > > > On Aug 19, Pavel Ivanov wrote: > > >> No, it's not reasonable for semi-sync to lock/unlock LOCK_plugin. > > >> It's plugin infrastructure that does that. > > >> > > >> I've actually was terrified to learn that each call into semi-sync > > >> plugin is surrounded with pthread_rwlock_rdlock/ > > >> pthread_rwlock_unlock (which is not cheap I believe). And also for > > >> each such call it "locks"/"unlocks" the semi-sync plugin. And > > >> although "locking" plugin avoids locking LOCK_plugin when plugin is > > >> linked statically, "unlocking" doesn't do that. > > > > > Sure, but macro FOREACH_OBSERVER inside rpl_handler.cc doesn't use > > this function. It uses plugin_unlock_list() which always locks > > LOCK_plugin. > > > > BTW, MariaDB still supports compiling semi-sync plugins dynamically, > > but it seems that it doesn't do anything against unloading semi-sync > > plugins in the middle of transactions. Did anyone think about this? > > Judging from the replication plugin API - I don't think so. > > But if it adds that much overhead, I suppose we'll need to fix it. > Then we fix the unloading too. > > Regards, > Sergei > > _______________________________________________ > Mailing list: https://launchpad.net/~maria-developers > Post to : maria-developers@lists.launchpad.net > Unsubscribe : https://launchpad.net/~maria-developers > More help : https://help.launchpad.net/ListHelp > -- Mark Callaghan mdcal...@gmail.com
_______________________________________________ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp