Re: thread safe dlerror()

[David-Sarah Hopwood <david.hopwood@xxxxxxxxxxxxxxxxxxxxxxxxxx>]

Geoff Clare wrote:
> Nick Stoughton <nick@usenix.org> wrote, on 25 Feb 2009:
>> In this case, the aardvark was addressed during the face-to-face
>> meeting, Feb 27 - Mar 1, 2007, at IBM, Austin, Texas.
> [snip] 
>> The attendees at the meeting were: Andrew Josey, Nick Stoughton, Don
>> Cragun, Larry Dwyer, Mark Brown, Ulrich Drepper, David Clissold, Geoff
>> Clare, and Cathy Fox. If any of us have better notes on why we rejected
>> this aardvark, now would be a good time to share them!
> 
> I found my notes, but they don't shed any more light.
> 
> I don't recall clearly, but I think the point of the rejection is
> that, since dlerror() is not required to be thread-safe, if a
> multi-threaded application calls dlerror() the behaviour is
> undefined. Therefore implementations where dlerror() is
> thread-specific are already allowed (because that is one of the many
> behaviours allowed for "undefined behaviour").

No, that's clearly wrong. For example, suppose only threads A and B
call dl* functions, and:

 - thread A calls dlopen
 - thread A synchronizes with thread B, e.g. using a semaphore
 - thread B calls dlerror

The current wording requires thread B's call to dlerror to return the
error set by thread A's call to dlopen. So a thread-specific dlerror
is not conforming.

-- 
David-Sarah Hopwood ⚥