libtool-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Use GetErrorMode if it is available (on Windows Vista and above).


From: Ralf Wildenhues
Subject: Re: Use GetErrorMode if it is available (on Windows Vista and above).
Date: Tue, 12 Jan 2010 21:19:50 +0100
User-agent: Mutt/1.5.20 (2009-10-28)

Hi Peter,

* Peter Rosin wrote on Tue, Jan 12, 2010 at 11:00:17AM CET:
> Without the patch, a separate thread of the process could be relying on
> the error mode to have some specific flag. Then, during a small window
> the loadlibrary loader clears some vital error mode flag since it has
> to set a temporary error mode (which might be insufficient for that other
> thread) to retrieve the existing error mode. There is a possibility that
> things go downhill due to that race. With the patch (and GetErrorMode
> support) the loader can fail critical errors (i.e. no irritating popup
> dialog) without clobbering other error mode flags in the process.

I'm still not sure I understand.  FWIW, in Libtool 2.x, we decided that
internal locking in libltdl was not feasible/possible correctly, and we
now require that users of libltdl do not call its functions
simultaneously from different threads.  In practice, that also means
that different threads may not call the underlying loader functions (be
that dlopen or LoadLibrary) at the same time, but I'm not sure whether
we communicate that in the manual.

Does the above descriptions only hold for LoadLibrary-related functions
(in which case that seems to be a user error in the code using libltdl)
or for any kind of library functions that set an error mode?  Is "error
mode" on w32 something akin to errno?

> That said, a potential race is still there since the error mode is
> process global and we are trying to save the current error mode and
> restore it afterwards, some other thread might do the same and we'd get
> into an inconsistent state if unlucky. There's no way to deal with that
> though, short of adding some locking mechanism and requiring client code
> to follow our lead.

That sounds like we may simply need to document that the client code
needs to employ locking so that libltdl functions are not called
simultaneously as function set X, X being?

> >Have you tested it on some system that has GetErrorMode (Vista) and some
> >that doesn't (something older)?
> 
> I have tested on Wine (w/ GetErrorMode) and XP (w/o). It behaves as
> designed on both AFAICT, and I get the same number of irritating popups
> with and without the patch when I run the testsuite.

Thanks,
Ralf




reply via email to

[Prev in Thread] Current Thread [Next in Thread]