On 1/21/22 23:19, Dimitry Sibiryakov wrote:
Adriano dos Santos Fernandes wrote 21.01.2022 20:08:
1) Disable unload timer in PluginManager in MacOS.

Fastest and simplest (or any other way to disable plugins unload).


2) Makes it possible for engine plugin to relive when it was shut down
and its entry point is called again. I have tested this solution and it
seems to work, but some details must be more tested, like
shutdown/relive of trace's ConfigStorage. In any case, with active
sandbox code it will never really unload the libraries, just the plugins.

3) Disable things related to sandbox
(https://paulbeachsblog.blogspot.com/2021/01/firebird-embedded-in-sandboxed-macos-app.html)

Sandbox was not added as a toy just to play with ObjC - it's really needed to users (embedded use in sandbox is nice thing), i.e. disabling it is not a way to go.


I think 1 is the way to go.

Opinions?

  Option 2 seems to be right one from my POV.
  Every plugin should not rely on undocumented unloading moment

worse here is that it's documented but broken in some builds...
but I agree that we can't rely on unloading currently

, so initialization in the entry point and finalization in doCleanup for all plugin-related things and initialization in constructor and finalization in destructor for every library-related things should be the right behavior for every plugin including engine itself.   It would be nice if these time frames weren't crossed but it seems that there is nothing we can do for that.


Longterm option 2 should be used. But for FB3 and may be fb4 option 1 is a way to go.




Firebird-Devel mailing list, web interface at 
https://lists.sourceforge.net/lists/listinfo/firebird-devel

Reply via email to