Plugins in C | Hacker News Reader

Plugins in C

eli.thegreenplace.net

51 pointsmalloc4711 comments

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 was kind of surprised too since Eli is seems pretty smart. Perhaps I'm missing something?

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.

Could you provide an example of this so us neophytes could learn from it?

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)

On a related note: Be wary of the dlclose() function, it may not necessarily free any resources[1] and not every libc implements it correctly[2].

1. http://www.openwall.com/lists/musl/2012/08/20/1 2. http://www.openwall.com/lists/musl/2012/08/23/20

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

Here's the link to the intro article, all in Python3.

http://eli.thegreenplace.net/2012/08/07/fundamental-concepts...

"While C itself is a relatively rigid language"

I use libpeas

bye

Reply on news.ycombinator.com