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.

Author plynch76
Recipients brian.curtin, loewis, meador.inge, plynch76, r.david.murray, tim.golden
Date 2012-04-16.16:38:39
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <CADde8OdjAxKJRzWhqjzvq9G1y6M=CxP-YE5vVrTv=m_X8Vy+Zg@mail.gmail.com>
In-reply-to <CADde8OcPzm+P92Dkee8_Tu6YH5A=1Sqj0XKWWYBYk9g3xfFeWQ@mail.gmail.com>
Content
Just to update:-

I've run this pretty extensively on multiple systems (XP x86 & Win7 64-bit)
and it appears to behave as expected (haven't checked it on Linux).  I have
that code being called in 100s of unit tests.

For python 3.1, would it make sense to add it as a ForceUnload function??
- for safety bail out if handle was not None when passed into the
constructor?  i.e. if somebody has accessed an independently loaded DLL,
they will pass in the handle when constructing the CDLL object.  Disallow
ForceUnload in that case.  ForceUnload will only be allowed in cases where
we created that type by passing in the path to the DLL.

I'll be using this code as a local patch, so no rush to put it into 3.1 etc.

thanks for all the info - much appreciated :)

Pat.

On 16 April 2012 15:04, Pat Lynch <report@bugs.python.org> wrote:

>
> Pat Lynch <plynch76@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@bugs.python.org> wrote:
>
> >
> > Martin v. Löwis <martin@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@bugs.python.org>
> > <http://bugs.python.org/issue14597>
> > _______________________________________
> >
>
> ----------
>
> _______________________________________
> Python tracker <report@bugs.python.org>
> <http://bugs.python.org/issue14597>
> _______________________________________
>
History
Date User Action Args
2012-04-16 16:38:39plynch76setrecipients: + plynch76, loewis, tim.golden, r.david.murray, brian.curtin, meador.inge
2012-04-16 16:38:39plynch76linkissue14597 messages
2012-04-16 16:38:39plynch76create