Module initialization problem when using COM

[Mark Hammond]

Robin Boerdijk wrote in message

>But you would also expect the .dll of the extension module to be unloaded
>and reloaded so that the state of the .dll is cleared. As Christian
>suggests, the .dll somehow doesn't  get unloaded and reloaded an I wonder
if
>this isn't a VB problem. Maybe the following may shed some light into the
>matter.

Not necessarily.  Recall that the only thing to have happened is that the
last Python object has been destroyed.  This does not imply the client has
(or is about to) unload the DLL.  Further, VB does not know that this is the
last Python object, nor indeed does it know it is using Python15.dll at all.

COM does have a call CoFreeUnusedLibraries() which should force the DLLs
with refcounts of 0 to be unloaded.  However, it is unreasonable to expect
VB to call this whenever it releases any COM reference.  This is likely to
be called either at idle time, or when some memory threshold has been
reached (or even possibly as part of VB garbage collection - who knows?)

>As a workaround to our original problem, we moved the CreateObject() to the
>Form_Load() sub of VB so that it would only be called once per instance of
>the VB program. However, the problem is still there because when we restart
>the program within the VB development environment (so that CreateObject()
is
>called again), the counter of our test extension module is incremented and
>not cleared to zero. Only when we build a stand-alone executable can we
stop
>and restart the program without problems (which implies that everything
gets
>unloaded and reloaded as expected).

Another way would be to force a circular reference to your object, or create
a single, immortal COM object (ie, as your server is created, the server
creates yet another Python COM object, and stores it in a module global.
Thus the DLL ref count will never hit 0.)

>> Either way, it does appear that this is the underlying ILU problem.  I
>would
>> guess we could invoke the same behaviour from a test program that init'd
>> then finalized then re-init'd Python before again using ILU.  Is this
>> possible to confirm?
>
>I'd be happy to try a few of these things if only I understood you want to
>be done exactly ;-)

It appears it should be possible to see with the following code fragment:
for (i=0;i<2;i++) {
  Py_Initialize();
  mod = PyImport_ImportModule("the ilu module");
  Py_DECREF(mod);
  Py_Finalize();
}

>(Note that the problem is not in ILU. ILU just complains about it. The
>"empty" test module from my original post is probably all that is needed
for
>testing things.)

Yes, but it is now unclear to me if it is indeed broken.  Given that Python
is being finalized, the behaviour we are seeing is correct.

It could be argued the issue is whether PythonCOM is correct in finalizing
and initializing Python in this way - but I can't see a reasonable
alternative...

IMO, the _real_ issue is that Python (and/or its modules) are not capable of
being reinitialized without the DLL being "physically" unloaded, and it
should be.  It is unclear to me if anything other than ILU is seriously
upset that this happens.

So the real question is: "yes, this happens, and for good reason.  Who is it
a problem for and why?"

[Other than PythonCOM itself probably - this may well cause some leaks in
the PythonCOM module init function - which brings me back to a different
issue - how does a module know it is being cleaned up by Python?
Aaarrrggg... :-]

Mark.