Module system: last call for objections

Michael Fair michael@daclubhouse.net
Thu, 02 Aug 2001 15:08:55 -0700


> > Question: is it possible for the 'end()' function to fail?
> 
> well, gnc_module_unload can fail (if you pass it a bogus module arg,
> for example) so there's room for passing information that the end
> handler has failed.  It probably makes sense for the end handler to
> return an int too, just so the upper levels can have some way of
> knowing that something failed in the unload process.  However, if you
> call unload() on a valid module with 0 refcount, it *will* be
> dlclose()d no matter what the end handler returns... too uncertain to
> leave it hanging around half-unloaded.

Let's also not assume that our module writers know what the hell
they are doing.  We should anticipate that the module authors
are going to write buggy software that make the modules fail
upon loading/unloading/functioning, dereferencing null pointer 
values, and otherwise just do bad things.  Making GNUCash robust 
and being able to debug which modules are misbehaving is going to 
be an invaluable tool since we are going to be "blindly" 
incorporating other people's code (maybe not in the code base 
directly, but in the field on the clients machines).

I don't know exactly what the correct behavior should be, and
we don't need to solve all these problems on the initial 
implementation (though it helps to get the framework right the
first time) and I think we would be remiss if we didn't at 
least address the buggy modules problem.

-- Michael --