Open marvin2k opened 10 years ago
I can see the appeal, but now that there is a dynamic plugin system, I wonder if it is not just a bad idea to remove it (I mean, typelib registry import/export yells "pluginify-me !").
On Wed, Aug 6, 2014 at 8:57 AM, marvin2k notifications@github.com wrote:
Hi,
while skimming through the code, I saw that the typelib_ruby.so is linked https://github.com/orocos-toolchain/typelib/blob/master/bindings/ruby/CMakeLists.txt#L64 to typeLang_csupport by the linker because addStandardTypes https://github.com/orocos-toolchain/typelib/blob/master/bindings/ruby/ext/registry.cc#L563 is called in registry.cc. Additionally, typeLang_csupport is registered https://github.com/orocos-toolchain/typelib/blob/master/lang/csupport/plugin.cc as dynamic plugin via the plugin-manager (differently than the tlb and idl plugins...). So the typeLang_csupport-object is loaded into memory twice in the ruby-binding? This might lead into problems if global symbols are present?
Anyways, I would ask: Why there is a dynamic plugin system at all? Couldn't we simplify all this by eliminating the complete pluginmanager? Nobody uses this to dynamically load additional objects into typelib after it is linked and installed? Or?
I know this is quite intrusive, especially for such a deep-down-the-stack module. But especially this is the reason to keep typelib as small and simple as possible.
Greetings
— Reply to this email directly or view it on GitHub https://github.com/orocos-toolchain/typelib/issues/10.
What is the benefit of "pluginifying" parts of the library? Nobody is going to reuse it elsewhere. We are no proprietary company, if someone wants to change something a recompilation is easy, and it provides the compiler/linker errors at compile time. Maintaining plugins and a plugin-architecture comes with a cost. Saving memory if parts are not used? Pah, just remove modules at the linker-stage. Or wait until link-time-optimization works reliably.
Binaries once deployed should work. Using plugins increases the runtime-risk of failing after deployment -- for numerous reasons nobody can control.
Using syskit to handle such fails at runtime does not help as the deployed binaries themself contain the error -- syskit would have to update and recompile the whole stack -- a cool idea for long-term autonomy of robots ;-)
Hi,
while skimming through the code, I saw that the typelib_ruby.so is linked to typeLang_csupport by the linker because addStandardTypes is called in registry.cc. Additionally, typeLang_csupport is registered as dynamic plugin via the plugin-manager (differently than the tlb and idl plugins...). So the typeLang_csupport-object is loaded into memory twice in the ruby-binding? This might lead into problems if global symbols are present?
Anyways, I would ask: Why there is a dynamic plugin system at all? Couldn't we simplify all this by eliminating the complete pluginmanager? Nobody uses this to dynamically load additional objects into typelib after it is linked and installed? Or?
I know this is quite intrusive, especially for such a deep-down-the-stack module. But especially this is the reason to keep typelib as small and simple as possible.
Greetings