design choices for a loadable module interface

[Jeffrey Hutzelman]

--On Friday, June 04, 2010 04:51:18 PM -0500 Nicolas Williams 
<Nicolas.Williams at oracle.com> wrote:

> Really, let's hear good reasons to not do the dlsym()-memoized-via-
> internal-vtables (which are then NOT part of the ABI).  I can't think of
> any.

Well, it's about what happens when you want a single plugin to provide more 
than one thing, like multiple related PA types or a PA type and an AD type 
or whatever.  As it is, you have specific "types" of extensions, the plugin 
framework has to know what the types are and what the interface is to each 
type, and you are restricted to each shared object containing exactly one 
extension of exactly one type.  A register_foo()-style interface eliminates 
this tight binding and the corresponding abstraction violation (*).  Of 
course, the price is all of the problems you mentioned.

Once the design decision has been made that one-extension-per-shared-object 
is acceptable, memoized-dlsym() definitely seems like the right answer.

(*) Of course, there are other ways to abstract knowledge of each plugin 
ABI away from the plugin framework.

-- Jeff