On 07/23/2016 03:25 AM, Pranith Kumar Karampuri wrote:
Emmanuel,
       I procrastinated too long on this :-/, It is July already :-(. I
just looked at the man page in Linux and it is a bit confusing, so I am
not sure how to go ahead.

For readdir_r(), I see:

DESCRIPTION
       This function is deprecated; use readdir(3) instead.

       The readdir_r() function was invented as a reentrant version of
readdir(3).  It reads
       the next directory entry from the directory stream dirp, and
returns it in the  call‐
       er-allocated  buffer  pointed  to by entry.  For details of the
dirent structure, see
       readir(3).

For readdir(3) I see:
ATTRIBUTES
       For an explanation of the terms used in this section, see
attributes(7).

       ┌──────────┬───────────────┬──────────────────────────┐
       │Interface │ Attribute     │ Value                    │
       ├──────────┼───────────────┼──────────────────────────┤
       │readdir() │ Thread safety │ MT-Unsafe race:dirstream │
       └──────────┴───────────────┴──────────────────────────┘

       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), concur‐
       rent  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.


So should we do readdir() with external locks for everything instead?


Do you have any concrete examples of problems encountered due to the same directory stream being invoked from multiple threads?

Kaleb's recent patch [1] and the updated man page for readdir_r in linux [2] has some more context.

-Vijay

[1] http://review.gluster.org/14838
[2] https://manned.org/readdir_r



_______________________________________________
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

Reply via email to