apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Yann Ylavic <ylavic....@gmail.com>
Subject Re: 1.6 release timetable
Date Sat, 25 Mar 2017 14:57:49 GMT
On Sat, Mar 25, 2017 at 1:34 PM, Florian Weimer <fw@deneb.enyo.de> wrote:
> * Yann Ylavic:
>>         "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."
> It's been a bit of a struggle to get this right.

I think the confusion comes from the term "directory stream", which
people (at least me :p ) may read as underlying directory (i.e.
filesystem's), though it's the term used to talk about the DIR* in the
whole man page...

> People are really
> concerned about the case where multiple threads read from the same
> directory stream.  But how often does that happen in practice?

I now realize that there is no real thread-safety issue, it indeed
shouldn't happen to call readdir() concurrently on the same DIR, IMHO
the doc should say that it's simply undefined behaviour (actually I
thought it was the case with readdir_r too, so the readdir_r part is
the misleading one I think).

>> Are you thinking of the above editorial?
> I meant this part:
>   Preliminary: | MT-Unsafe race:dirstream | AS-Unsafe lock | AC-Unsafe
>     lock | See POSIX Safety Concepts.
> <https://www.gnu.org/software/libc/manual/html_node/Reading_002fClosing-Directory.html>
> “MT-Unsafe race:dirstream” doesn't make much sense because we don't
> have this as a category for memcpy because for some reason, it is
> “obvious” for memcpy that it's only thread-safe if it is called for
> completely separate arguments.

OK, got it now, thanks!

> I think the Solaris manual also does not mark readdir as thread-safe,
> implicitly suggesting to use readdir_r in multi-threaded programs.
> But this suggestion isn't helpful on Solaris, either.

So Solaris' readdir() does not return static data either.
Any idea of which system keeps doing this?

View raw message