This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Title: Free extension DLLs' handles during the Py_Finalize()
Type: Stage:
Components: Windows Versions:
Status: closed Resolution: rejected
Dependencies: Superseder:
Assigned To: tim.peters Nosy List: eric.snow, fdrake, gvanrossum, loewis, markovitch, mhammond, tim.peters
Priority: normal Keywords: patch

Created on 2000-09-29 19:02 by markovitch, last changed 2022-04-10 16:02 by admin. This issue is now closed.

File name Uploaded Description Edit
None markovitch, 2000-09-29 19:02 None
Messages (9)
msg34518 - (view) Author: Yakov Markovitch (markovitch) Date: 2000-09-29 19:02
msg34519 - (view) Author: Fred Drake (fdrake) (Python committer) Date: 2000-10-01 00:01
Assigned to one of our Windows guys for review.
msg34520 - (view) Author: Fred Drake (fdrake) (Python committer) Date: 2000-10-01 00:01
Assigned to one of our Windows guys for review.
msg34521 - (view) Author: Mark Hammond (mhammond) * (Python committer) Date: 2000-10-06 01:19
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

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 ;-)
msg34522 - (view) Author: Tim Peters (tim.peters) * (Python committer) Date: 2000-10-06 01:02
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.
msg34523 - (view) Author: Yakov Markovitch (markovitch) Date: 2000-09-29 19:09
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,    
msg34524 - (view) Author: Yakov Markovitch (markovitch) Date: 2000-10-06 09:54
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!)
msg34525 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2001-06-04 07:56
Logged In: YES 

I recommend to reject this patch. If such a feature is 
implemented, it should be implemented uniformly across 
platforms - i.e. on Unix, appropriate dlclose calls should 
be issued.

Furthermore, I don't see the problem with the DLLs being 
loaded. AFAIK, each DLL will be loaded only once, so even 
if the interpreter is stopped and started again, you get 
only one copy of the DLLs state per process, right? So 
what is the problem?

Finally, it seems reasonable that people embedding the 
interpreter might need to customize its code. It is 
possible that the finalization procedure of user A won't 
work for user B, e.g. because they require state to 
survive different activations and deactivations.
msg34526 - (view) Author: Guido van Rossum (gvanrossum) * (Python committer) Date: 2001-08-09 15:49
Logged In: YES 

Rejected, trusting MvL's judgement.
Date User Action Args
2022-04-10 16:02:27adminsetgithub: 33239
2018-05-16 18:12:24eric.snowsetnosy: + eric.snow
2000-09-29 19:02:15markovitchcreate