Workaround for which problem?

On Tue, Aug 20, 2013 at 8:17 AM, MARK CALLAGHAN <mdcallag@gmail.com> wrote:
> Is the workaround to use static rather than dynamic plugins?
>
>
> On Tue, Aug 20, 2013 at 7:31 AM, Sergei Golubchik <serg@mariadb.org> wrote:
>>
>> Hi, Pavel!
>>
>> On Aug 20, Pavel Ivanov wrote:
>> > On Tue, Aug 20, 2013 at 1:09 AM, Sergei Golubchik <serg@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
> mdcallag@gmail.com