[issue14597] Cannot unload dll in ctypes until script exits

Pat Lynch report at bugs.python.org
Mon Apr 16 16:04:56 CEST 2012


Pat Lynch <plynch76 at gmail.com> added the comment:

ok, that's fair enough if most usage of ctypes is from people accessing
system libraries :)

I wouldn't have thought my usage was that weird though (given the strength
of using python for unit testing).

In local tests, adding a function CDLL::ForceUnloadDll  (which just calls
FreeLibrary(self._handle)) seems to work well.  I haven't done intensive
testing though at this point.  I could be missing something though.

thanks,
Pat.

On 16 April 2012 14:45, Martin v. Löwis <report at bugs.python.org> wrote:

>
> Martin v. Löwis <martin at v.loewis.de> added the comment:
>
> In principle, it should be possible (but perhaps not desirable, see below)
> to call FreeLibrary in a CDLL's __del__. However, since this would be a new
> feature, it can't go into 2.7. Patches are welcome; make sure to support
> both FreeLIbrary and dlclose.
>
> There is a general issue with closing/freeing DLLs: if they are still
> referenced somewhere (e.g. in an atexit function, a C++ virtual method
> table, or on the call stack of another thread), then a later access to the
> code will crash the interpreter. In a typical DLL today (including all
> Python extension modules), the likelihood of crashes is close to 100%. For
> that reason, it's probably not a good idea to have ctypes auto-close DLLs;
> instead, it should be an opt-in mechanism.
>
> For most ctypes uses, closing is irrelevant, since people typically access
> system libraries that are independently loaded anyway, so closing them
> would not have any effect.
>
> ----------
> nosy: +loewis
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue14597>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14597>
_______________________________________


More information about the Python-bugs-list mailing list