search

orocos-toolchain / typelib

Universal C++ type library with bindings to scripting languages.
Other
10 stars 26 forks source link

Proposal: keep typelib managable -- remove dynamic plugin system #10

Open marvin2k opened 10 years ago

marvin2k commented 10 years ago

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

doudou commented 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.

marvin2k commented 10 years ago

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 ;-)