Author plynch76
Recipients brian.curtin, loewis, meador.inge, plynch76, r.david.murray, tim.golden
Date 2012-04-16.14:04:55
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
In-reply-to <>
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.


On 16 April 2012 14:45, Martin v. Löwis <> wrote:

> Martin v. Löwis <> 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 <>
> <>
> _______________________________________
Date User Action Args
2012-04-16 14:04:56plynch76setrecipients: + plynch76, loewis, tim.golden, r.david.murray, brian.curtin, meador.inge
2012-04-16 14:04:56plynch76linkissue14597 messages
2012-04-16 14:04:56plynch76create