From: stephan b. <st...@s1...> - 2005-03-02 18:18:04
|
Hiya! Last night i came up with a theory for solving what i will call the "dangling factory" problem of closing plugins. Consider this scenario: - Open Plugin X. That plugin contains several classes which automatically register with P::Factory<SomeClass>, so that our factory now knows about them. - At some point we close the plugin. - Someone calls Factory<SomeClass>::instance().create( "SomeClass" ). Doh! The factory entry is still in Factory<>, but points to memory which has been released. One of three things will happen: a) If we're lucky, an immediate segfault. Undefined behaviour. We could inject marker symbols into plugin DLLs and SharedLib could theoretically check for those to perhaps avoid a segfault, and throw SharedLibException instead. b) If we're unlucky, something else is at that address which is call-compatible with our factory and we call that code. Undefined behaviour. c) Something "really odd" happens and it somehow continues to work. (Probably "not possible".) Undefined behaviour. Now, let's consider the factory registration process, as it exists right now in libs11n and in P2: when a DLL (or the main app) is opened, statically-initialized POD variables get initialized. The initialization code contains a function call to our factory registration. This is what i call the "static initialization trick" of classloader registration. That trick works all fine and well, but has one significant problem: closing the DLL in which it exists leaves the factory entry lying around. The scoped_signal class i posted the other night holds the key to that problem: don't use PODs to initialize the factory registration, but use static OBJECTS, instead. Now we have, instead of a pod, something like this: struct MyReg { static MyReg bogo; MyReg() { register factory ... } ~MyReg() { deregister factory ... } }; MyReg MyReg::bogo = MyReg(); IN THEORY, when we do dlclose(), the static destruction phase will kick in and destroy bogo. Lass mich IN THEORY /stark/betonen/. What i do not know is if dlclose() ever calls static destruction, especially if the dlopen() call uses the equivalent of RESOLVE_IMMEDIATELY (or whatever it's called) to resolve all symbols at the moment it's loaded (instead of lazy resolution). To be clear: this does NOT solve the whole inherent problem of dangling resources when closing a DLL. It does solve the problem of dangling factories (in theory). ?????????? Could this work ??????????? -- ----- st...@s1... http://s11n.net "...pleasure is a grace and is not obedient to the commands of the will." -- Alan W. Watts |