[pclasses-devel] theoretical solution to plugin registry found

[stephan b. <st...@s1...>]

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