Linux APIs

Line 3:

== File descriptors ==

* Since 2.1.69 and glibc 2.1, <tt>pread(2)</tt> and <tt>pwrite(2)</tt> have allowed <tt>read(2)</tt>- and <tt>write(2)</tt>-like behavior on a file descriptor from a specified offset, without updating the offset. This allows for the atomic equivalent of an <tt>lseek(2)</tt> and an I/O, particularly useful when multiple threads are working with the same file descriptor (since file descriptor offset is shared across the process).

* Since 2.6.16, the <tt>openat(2)</tt> system call can <tt>open(2)</tt> a file relative to an open directory provided as the first argument. As the man page says:

~~<pre> openat() and other similar system calls suffixed "at" are supported for~~

~~two reasons.~~

~~First, openat() allows an application to avoid race conditions that~~

~~could occur when using open(2) to open files in directories other than~~

~~the current working directory. These race conditions result from the~~

~~fact that some component of the directory prefix given to open(2) could~~

~~be changed in parallel with the call to open(2). Such races can be~~

~~avoided by opening a file descriptor for the target directory, and then~~

~~specifying that file descriptor as the dirfd argument of openat().~~

~~Second, openat() allows the implementation of a per-thread "current~~

~~working directory", via file descriptor(s) maintained by the applica‐~~

~~tion. (This functionality can also be obtained by tricks based on the~~

~~use of /proc/self/fd/dirfd, but less efficiently.)</pre>~~

* Since 2.6.23, the <tt>open(2)</tt> system call accepts the <tt>O_CLOEXEC</tt> flag (as does <tt>recvmsg(2)</tt> and the corresponding <tt>MSG_CMSG_CLOEXEC</tt> flag). This atomically sets the close-on-exec flag upon update of the dtable, protecting against a race condition arising from <tt>fork(2)</tt>+<tt>exec(2)</tt> calls in other threads.

** Since 2.6.24, <tt>fcntl(2)</tt> implements a <tt>F_DUPFD_CLOEXEC</tt> operation, mating <tt>O_CLOEXEC</tt> to <tt>F_DUPFD</tt>.

Linux APIs: Difference between revisions

Dank (talk | contribs)

@@ Line 3: / Line 3: @@
 == File descriptors ==
 * Since 2.1.69 and glibc 2.1, <tt>pread(2)</tt> and <tt>pwrite(2)</tt> have allowed <tt>read(2)</tt>- and <tt>write(2)</tt>-like behavior on a file descriptor from a specified offset, without updating the offset. This allows for the atomic equivalent of an <tt>lseek(2)</tt> and an I/O, particularly useful when multiple threads are working with the same file descriptor (since file descriptor offset is shared across the process).
-* Since 2.6.16, the <tt>openat(2)</tt> system call can <tt>open(2)</tt> a file relative to an open directory provided as the first argument. As the man page says:
-<pre>       openat() and other similar system calls suffixed "at" are supported for
-       two reasons.
-       First,  openat()  allows  an  application to avoid race conditions that
-       could occur when using open(2) to open files in directories other  than
-       the  current  working directory.  These race conditions result from the
-       fact that some component of the directory prefix given to open(2) could
-       be  changed  in  parallel  with the call to open(2).  Such races can be
-       avoided by opening a file descriptor for the target directory, and then
-       specifying that file descriptor as the dirfd argument of openat().
-       Second,  openat()  allows  the  implementation of a per-thread "current
-       working directory", via file descriptor(s) maintained by  the  applica‐
-       tion.   (This functionality can also be obtained by tricks based on the
-       use of /proc/self/fd/dirfd, but less efficiently.)</pre>
 * Since 2.6.23, the <tt>open(2)</tt> system call accepts the <tt>O_CLOEXEC</tt> flag (as does <tt>recvmsg(2)</tt> and the corresponding <tt>MSG_CMSG_CLOEXEC</tt> flag). This atomically sets the close-on-exec flag upon update of the dtable, protecting against a race condition arising from <tt>fork(2)</tt>+<tt>exec(2)</tt> calls in other threads.
 ** Since 2.6.24, <tt>fcntl(2)</tt> implements a <tt>F_DUPFD_CLOEXEC</tt> operation, mating <tt>O_CLOEXEC</tt> to <tt>F_DUPFD</tt>.