apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Florian Weimer ...@deneb.enyo.de>
Subject Re: 1.6 release timetable
Date Sat, 25 Mar 2017 12:39:03 GMT
* Yann Ylavic:

> [Resend to the whole list, sorry Florian for private message]
> On Sat, Mar 25, 2017 at 1:20 PM, Yann Ylavic <ylavic.dev@gmail.com> wrote:
>> Right, modern readdir()s seem to be thread-safe but with regard to
>> different directories only, at least Linux' man page states:
>>         "In the current POSIX.1 specification (POSIX.1-2008),
>> readdir() is not required to be thread-safe.  However, in modern
>> implementations (including the glibc implementation), concurrent calls
>> to readdir() that specify different directory streams are thread-safe.
>> In cases where multiple threads must read from the same directory
>> stream, using readdir() with external synchronization is still
>> preferable to the use of the  deprecated readdir_r(3) function.  It is
>> expected that a future version of POSIX.1 will require that readdir()
>> be thread-safe when concurrently employed on different directory
>> streams."
> Maybe we could simply forward this requirement (external
> synchronization) in the definition/usage of apr_dir_read()...

That's reasonable, but it's counterproductive to document that.  Most
programmers will assume that they have to perform special locking for
this function, which isn't true.  There really isn't anything special
about readdir and apr_dir_read.  It's mostly an accident that readdir
was labeled as thread-unsafe, which led to this mess, so please do not
repeat this for apr_dir_read.

View raw message