Why not export a struct with function pointers like everyone else? You should take a look at how VST plugins are implemented.
You load the dlo, call a function passing in your own struct of application functions and get back a struct of plugin functions. No weird naming conventions needed, easily version-able. Tried and true.
I don't know whether this was the author's intent, but it's better to start simpler (not in designs but in concepts - arguably, structs are simpler than funky naming conventions) for the beginner and less experienced dev. The struct method is a powerful one, yet not one grokked simply by the neophyte. There probably needs to be a Part II.
On the contrary, setting up a regime of specially-named functions is error-prone and clunky, and structures with function pointers are a language idiom in C, and, finally, if you're too new to the language to understand function pointers, you can't use either technique, because both rely on function pointers.
Ultimately, the real problem is that teaching bad designs to people because they're new to the language is counterproductive.
What weird naming conventions? There's only one symbol in each plugin the application knows about, the init_<pluginname> function, but at least one symbol is usually necessary.
Do you mean the plugins calling PluginManager functions to register hooks? I just wanted to present a simple method without a lot of code. Using structs is an alternative, more convenient in some cases. One problem with it is that it imposes an ABI, while one registration function per hook does not.
Anyhow, this was just a basic example showing how plugins can work. I do plan to explore alternatives in the future, and specifically looking at existing pluggable applications (Apache, for instance)
If you really need to demand-load and demand-unload lots and lots and lots of plugins --- and that's the only design I can think of where dlclose matters, but maybe there are others --- fork a plugin host process from the main process, and kill it off when you're done with the plugins. You can use anonymous shared memory to communicate between the two processes (since there's a simple parent/child relationship).
11 comments
[ 4.6 ms ] story [ 36.2 ms ] threadbye
You load the dlo, call a function passing in your own struct of application functions and get back a struct of plugin functions. No weird naming conventions needed, easily version-able. Tried and true.
Ultimately, the real problem is that teaching bad designs to people because they're new to the language is counterproductive.
Do you mean the plugins calling PluginManager functions to register hooks? I just wanted to present a simple method without a lot of code. Using structs is an alternative, more convenient in some cases. One problem with it is that it imposes an ABI, while one registration function per hook does not.
Anyhow, this was just a basic example showing how plugins can work. I do plan to explore alternatives in the future, and specifically looking at existing pluggable applications (Apache, for instance)
1. http://www.openwall.com/lists/musl/2012/08/20/1 2. http://www.openwall.com/lists/musl/2012/08/23/20
http://eli.thegreenplace.net/2012/08/07/fundamental-concepts...