This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] readdir, readdir64 are thread-safe
- From: Zack Weinberg <zackw at panix dot com>
- To: Florian Weimer <fweimer at redhat dot com>
- Cc: GNU C Library <libc-alpha at sourceware dot org>
- Date: Tue, 11 Apr 2017 09:16:45 -0400
- Subject: Re: [PATCH] readdir, readdir64 are thread-safe
- Authentication-results: sourceware.org; auth=none
- References: <20170411113622.8C77B403B9917@oldenburg.str.redhat.com>
On Tue, Apr 11, 2017 at 7:36 AM, Florian Weimer <fweimer@redhat.com> wrote:
> They only modify the state in the dirstream argument, and we
> generally do not treat this as a reason to mark a function as
> not thread-safe. For an example, see random_r, which is marked
> as thread-safe even though the random state is not protected
> by a lock.
Hmm. There's two issues here: first, POSIX specifically allows
readdir to be not thread-safe (although it's unclear to me what that
actually means) so it might be appropriate to keep the annotation
around to warn people that there is a portability concern; second, if
you share a DIR object among threads, a call to readdir in one thread
will clobber the previous return value, which might still be live in
another thread. Is that sufficient reason to call the *function*
thread-unsafe? We don't have any good place to warn people about that
*other* than the documentation for readdir. (Note that the text of
the @deftypefun does a very bad job of explaining what the problem
is.)
zw