> On May 8, 2020, at 2:29 PM, Alan Carroll <[email protected]> > wrote: > > > > On Fri, May 8, 2020 at 3:17 PM Leif Hedstrom <[email protected] > <mailto:[email protected]>> wrote: > > It should get reloaded for the second, not for the first. As far as I > understand, this is fine, the Gancho made the code such that as long as > something uses some version of a plugin, it will be kept forever. > > > I am dubious of that claim - I don't remember anything like that. We should > ask Gancho, but IIRC the table of plugins for the remap doesn't track per > rule, so for a given configuration and plugin, there is only one version of > the plugin DSO loaded.
It’ll require some changes to the core, I’m just saying there’s nothing technical that would prevent two remaps to point to differently loaded .so’s. Multiple versions of the plugin can live simultaneously already, simply by the fact that remap structure is ref-counted and some request can linger for hours or days. Now, I guess I really don’t care much, as long as all the core plugins that supports both remap and global don’t limit how we use them (which it seemed at least option #2 would do, possibly #3 and #4 too?). Or, if you can tell me which plugin is having a problem here, I can look into fixing that problem (likely it’s my fault anyways). I still don’t fully understand the problem that anyone has here; As Gancho explained when the setting was added, it’s a marginal code change to fix the behavior in plugins that do have problems. We also added the “global” user-data slot table, to make it easier to share data between different plugins (such that you don’t lose the connection between the once loaded global instance, and the reloadable remap instances). The setting was added as “transitional” aid, making it easier to upgrade to 9.0.x without having to fix internal plugins immediately. — Leif
