Proposal: keep typelib managable -- remove dynamic plugin system

[marvin2k]

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]

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 [email protected] 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
#10.

[marvin2k]

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