+1 on the general idea to make the reloadability customizable per plugin.
However, I think it'd be more simple, cleaner and intuitive to not tie it to
whether or not a plugin is used both as a global and remap plugin.
In other words, approach (1) below but, instead of calling it "@global", we
could add a param which says "@reloadable=false" (the default value for
"@reloadable" can be "true").
The same param can then be used, when we eventually add relodability to global
plugins as well.
Thoughts?
On Thursday, May 7, 2020, 05:24:09 PM PDT, 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.
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.
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".
I'm willing to see if I can make this work, but I would like to have some
feedback on the preferred approach first.
