[Patches] [Patch #101713] Free extension DLLs' handles during the Py_Finalize()

[noreply@sourceforge.net]

Patch #101713 has been updated. 

Project: 
Category: Windows
Status: Open
Summary: Free extension DLLs' handles during the Py_Finalize()

Follow-Ups:

Date: 2000-Sep-29 12:09
By: Markovitch

Comment:
This patch is intended to fix the following problem:
Python on Windows never frees DLLs loaded as extension. Whenever it's not a big problem when the interpreter is being used in a standart way, it becomes THE problem (or even a disaster) when the interpreter DLL is dynamically 
initialized/finalized from one process many times during single run.
Moreover, even in case of single initialization there is a trap - DLLs loaded by mistake are unloaded only then a process finishes (e.g. suppose there is a foo.dll in the current directory and foo.dll is NOT a Python extension;
"import foo" ends up with error, but foo.dll will be anging in process' address space!)

This patch
    1) frees a DLL handle in case of it has no proper initialization funcion
    2) registers in an internal array all handles of successfully loaded dynamic extensions
    2) frees all registered handles during Py_Finalize()
    
Yakov Markovitch,
markovitch@iso.ru    
-------------------------------------------------------

Date: 2000-Sep-30 17:01
By: fdrake

Comment:
Assigned to one of our Windows guys for review.
-------------------------------------------------------

Date: 2000-Sep-30 17:01
By: fdrake

Comment:
Assigned to one of our Windows guys for review.
-------------------------------------------------------

Date: 2000-Oct-05 18:02
By: tim_one

Comment:
Mark, you got anything to say about this?  Can't say I've ever noticed a problem here.  Note that "the patch" is actually a .zip archive, and it takes a little effort to sort out what's what.
-------------------------------------------------------

Date: 2000-Oct-05 18:19
By: mhammond

Comment:
I agree we should close handles that we can't use as extension modules.

I am quite skeptical of the unloading of modules, tho.  Python simply doesn't provide enough cleanup semantics to guarantee we are finished with the module at Py_Finalize() time.  Indeed, extension modules are one main reason why Python often can not handle multiple Py_Initialize()/Py_Finalize() calls in the same process.

I think that Python needs to grow module termination semantics.  Something like, at Py_Finalize time:

Try and find function "term_{module}"
If function exists:
  call function
  free handle
else:
  pass

Thus - only modules that have gone to the trouble of providing a finalize function can be trusted to be unloaded.

On one hand, the addition of the map means we _are_ in a better position for better finalization semantics on Windows.  On the larger hand, module finalization semantics must be cross-platform anyway.

So - while I acknowledge the problem, I don't believe this alone is a reasonable solution. 

Marking as postponed, and assigning back to Tim, so he can rule on the next step....  This came up a number of years ago, and Guido agreed "better" semantics were needed.  Sounds like PEP material.  I guess I _do_ care enough about this issue to own a PEP on it, as long as no-one needs the PEP finalized this year ;-)
-------------------------------------------------------

Date: 2000-Oct-06 02:54
By: Markovitch

Comment:
Yes, I agree with Mark, but there is the other side of the problem. Let's suppose that we have an application that uses the interpreter through dynamic loading (I mean through the LoadLibrary). It isn't likely to be directly, but the application can load/unload some other DLL which, in turn, uses an embedded interpreter. Now after freeing this DLL the application has ALL extensions which was used by this DLL loaded! (Though it hasn't the interpreter embedded at all!)
-------------------------------------------------------

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=101713&group_id=5470