Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
marvin2k opened this issue Aug 6, 2014 · 2 comments
Open

Comments

@marvin2k
Copy link
Contributor

marvin2k commented Aug 6, 2014

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
Copy link
Contributor

doudou commented Aug 8, 2014

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
Copy link
Contributor Author

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants