The Linux Programming Interface

Alternative I/O Models 1355

F_OWNER_TID

The pid field specifies the ID of a thread that is to be the target of “I/O pos-

sible” signals. The ID specified in pid is a value returned by clone() or gettid().

The F_GETOWN_EX operation is the converse of the F_GETOWN_EX operation. It uses the

f_owner_ex structure pointed to by the third argument of fcntl() to return the settings

defined by a previous F_SETOWN_EX operation.

Because the F_SETOWN_EX and F_GETOWN_EX operations represent process group

IDs as positive values, F_GETOWN_EX doesn’t suffer the problem described earlier

for F_GETOWN when using process group IDs less than 4096.

63.4 The epoll API

Like the I/O multiplexing system calls and signal-driven I/O, the Linux epoll (event

poll) API is used to monitor multiple file descriptors to see if they are ready for I/O.

The primary advantages of the epoll API are the following:

z The performance of epoll scales much better than select() and poll() when moni-

toring large numbers of file descriptors.

z The epoll API permits either level-triggered or edge-triggered notification. By

contrast, select() and poll() provide only level-triggered notification, and signal-

driven I/O provides only edge-triggered notification.

The performance of epoll and signal-driven I/O is similar. However, epoll has some

advantages over signal-driven I/O:

z We avoid the complexities of signal handling (e.g., signal-queue overflow).

z We have greater flexibility in specifying what kind of monitoring we want to

perform (e.g., checking to see if a file descriptor for a socket is ready for read-

ing, writing, or both).

The epoll API is Linux-specific, and is new in Linux 2.6.

The central data structure of the epoll API is an epoll instance, which is referred

to via an open file descriptor. This file descriptor is not used for I/O. Instead, it is a

handle for kernel data structures that serve two purposes:

z recording a list of file descriptors that this process has declared an interest in

monitoring—the interest list; and

z maintaining a list of file descriptors that are ready for I/O—the ready list.

The membership of the ready list is a subset of the interest list.

For each file descriptor monitored by epoll, we can specify a bit mask indicating

events that we are interested in knowing about. These bit masks correspond closely

to the bit masks used with poll().

The epoll API consists of three system calls:

z The epoll_create() system call creates an epoll instance and returns a file descriptor

referring to the instance.