Linux APIs

Line 2:

== File descriptors ==

* Since 2.6.23, the <tt>open(2)</tt> system call accepts the O_CLOEXEC flag (as does <tt>recvmsg(2)</tt> and the corresponding MSG_CMSG_CLOEXEC 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.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 F_DUPFD_CLOEXEC operation, mating O_CLOEXEC to F_DUPFD.

** 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>.

* <tt>[[epoll|epoll(7)]]</tt> was introduced in 2.5.44; it is in ways similar to [[FreeBSD APIs|FreeBSD's kqueue]] or Solaris's <tt>/dev/poll</tt> (one major advantage over <tt>poll(2)</tt> is that the pollfd structures need not be copied from user- to kernel-space with each invocation).

** [[FreeBSD]] aims to emulate <tt>[[epoll|epoll(7)]]</tt>, but they don't yet seem to have done so...

* Since 2.6.25 and 2.6.23 respectively, [[timerfd]] and [[signalfd]] system call families exist, supporting timer and signal-based operations via the file descriptor model (they are fully supported by <tt>poll(2)</tt>, [[epoll|epoll(7)]], etc). These roughly correspond to EVFILT_TIMER and EVFILT_SIG event filters in [[kqueue]]. Since 2.6.27, <tt>timerfd_create(2)</tt> supports TFD_CLOEXEC and TFD_NONBLOCK bits in the ''flags'' parameter, and <tt>signalfd(2)</tt> supports a corresponding SFD_CLOEXEC/SFD_NONBLOCK pair.

* Since 2.6.25 and 2.6.23 respectively, [[timerfd]] and [[signalfd]] system call families exist, supporting timer and signal-based operations via the file descriptor model (they are fully supported by <tt>poll(2)</tt>, [[epoll|epoll(7)]], etc). These roughly correspond to <tt>EVFILT_TIMER</tt> and <tt>EVFILT_SIG</tt> event filters in [[kqueue]]. Since 2.6.27, <tt>timerfd_create(2)</tt> supports <tt>TFD_CLOEXEC</tt> and <tt>TFD_NONBLOCK</tt> bits in the ''flags'' parameter, and <tt>signalfd(2)</tt> supports a corresponding <tt>SFD_CLOEXEC/SFD_NONBLOCK</tt> pair.

** In the course of 2.6.26 development, <tt>signalfd(2)</tt> saw an API change; the third parameter went from a (frankly baffling) ''masksize'' to an integer ''flags''. See the LKML thread [http://lkml.org/lkml/2007/6/5/392 "signalfd API issues"], and [http://lwn.net/Articles/225714/ this LWN article].

* The obsolete BSD implementation of [[asynchronous I/O]] is extended via the <tt>F_GETSIG</tt> and <tt>F_SETSIG</tt> subcommands to <tt>fcntl(2)</tt>.

Linux APIs: Difference between revisions

Dank (talk | contribs)

@@ Line 2: / Line 2: @@
 == File descriptors ==
-* Since 2.6.23, the <tt>open(2)</tt> system call accepts the O_CLOEXEC flag (as does <tt>recvmsg(2)</tt> and the corresponding MSG_CMSG_CLOEXEC 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.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 F_DUPFD_CLOEXEC operation, mating O_CLOEXEC to F_DUPFD.
+** 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>.
 * <tt>[[epoll|epoll(7)]]</tt> was introduced in 2.5.44; it is in ways similar to [[FreeBSD APIs|FreeBSD's kqueue]] or Solaris's <tt>/dev/poll</tt> (one major advantage over <tt>poll(2)</tt> is that the pollfd structures need not be copied from user- to kernel-space with each invocation).
 ** [[FreeBSD]] aims to emulate <tt>[[epoll|epoll(7)]]</tt>, but they don't yet seem to have done so...
-* Since 2.6.25 and 2.6.23 respectively, [[timerfd]] and [[signalfd]] system call families exist, supporting timer and signal-based operations via the file descriptor model (they are fully supported by <tt>poll(2)</tt>, [[epoll|epoll(7)]], etc). These roughly correspond to EVFILT_TIMER and EVFILT_SIG event filters in [[kqueue]]. Since 2.6.27, <tt>timerfd_create(2)</tt> supports TFD_CLOEXEC and TFD_NONBLOCK bits in the ''flags'' parameter, and <tt>signalfd(2)</tt> supports a corresponding SFD_CLOEXEC/SFD_NONBLOCK pair.
+* Since 2.6.25 and 2.6.23 respectively, [[timerfd]] and [[signalfd]] system call families exist, supporting timer and signal-based operations via the file descriptor model (they are fully supported by <tt>poll(2)</tt>, [[epoll|epoll(7)]], etc). These roughly correspond to <tt>EVFILT_TIMER</tt> and <tt>EVFILT_SIG</tt> event filters in [[kqueue]]. Since 2.6.27, <tt>timerfd_create(2)</tt> supports <tt>TFD_CLOEXEC</tt> and <tt>TFD_NONBLOCK</tt> bits in the ''flags'' parameter, and <tt>signalfd(2)</tt> supports a corresponding <tt>SFD_CLOEXEC/SFD_NONBLOCK</tt> pair.
 ** In the course of 2.6.26 development, <tt>signalfd(2)</tt> saw an API change; the third parameter went from a (frankly baffling) ''masksize'' to an integer ''flags''. See the LKML thread [http://lkml.org/lkml/2007/6/5/392 "signalfd API issues"], and [http://lwn.net/Articles/225714/ this LWN article].
 * The obsolete BSD implementation of [[asynchronous I/O]] is extended via the <tt>F_GETSIG</tt> and <tt>F_SETSIG</tt> subcommands to <tt>fcntl(2)</tt>.