> On May 7, 2020, at 18:24, Alan Carroll <[email protected]>
> wrote:
>
>
> As part of the ATS 9 upgrade, a feature was added so that remap plugins could
> have their DSO reloaded. This means not just the configuration, but the
> implementation itself. While very useful, this has some unfortunate side
> effects with plugins that are used in both a global and remap context. To
> alleviate this, a configuration variable as added to disable the feature.
>
> Although reasonable, this is a rather heavy handed way to deal with the
> problem. What would be better is the ability to reload the DSO or not on a
> per remap plugin basis. I have a few ways this could be done:
>
> 1) Add the keyword "@global" to "remap.config". This would behave exactly as
> "@plugin" except it would prohibit reloading of the DSO for that plugin.
This was one of the suggestions brought up. I don’t know why it was shutdown.
>
> 2) Have the remap reload configuration check to see if the plugin is also a
> global plugin and disable remap DSO reload for that plugin.
I think this is worse, many plugins won’t have problems with a global not being
reloaded. Worse, many plugins works as either global or remap, but not both,
and this limits what the user can do.
>
> 3) Add a flag to the global plugin registry information which can be set
> during TSPluginInit which disables DSO reloading for that plugin, should it
> occur in "remap.config". This is similar to (2) but requires a plugin to
> prohibit DSO reloading. The call woud be TSPluginDSOReloadEnable(flag) and
> would only be valid when called from TSPluginInit.
>
> 4) As (3), except the flag is set by default and must be cleared to enable
> DSO reloading in "remap.config".
Either is fine. I think option 1 is by far the easiest and most flexible (let
the user decide, not the plugin).
— Leif
>
> I'm willing to see if I can make this work, but I would like to have some
> feedback on the preferred approach first.
>
