[linuxjm/LDP_man-pages.git] / draft / man7 / epoll.7

.\"
.\"  epoll by Davide Libenzi ( efficient event notification retrieval )
.\"  Copyright (C) 2003  Davide Libenzi
.\"
.\"  This program is free software; you can redistribute it and/or modify
.\"  it under the terms of the GNU General Public License as published by
.\"  the Free Software Foundation; either version 2 of the License, or
.\"  (at your option) any later version.
.\"
.\"  This program is distributed in the hope that it will be useful,
.\"  but WITHOUT ANY WARRANTY; without even the implied warranty of
.\"  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
.\"  GNU General Public License for more details.
.\"
.\"  You should have received a copy of the GNU General Public License
.\"  along with this program; if not, write to the Free Software
.\"  Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
.\"
.\"  Davide Libenzi <davidel@xmailserver.org>
.\"
.\" Japanese Version Copyright (c) 2004-2005 Yuichi SATO
.\"         all rights reserved.
.\" Translated Sat Jun 19 07:50:04 JST 2004
.\"         by Yuichi SATO <ysato444@yahoo.co.jp>
.\" Updated & Modified 2005-01-18, Yuichi SATO
.\" Updated 2006-07-14, Akihiro MOTOKI <amotoki@dd.iij4u.or.jp>
.\"         Catch up to LDP v2.34. epoll.4 is renamed to epoll.7.
.\" Updated 2007-09-07, Akihiro MOTOKI, LDP v2.64
.\" Updated 2008-04-08, Akihiro MOTOKI, LDP v2.79
.\" Updated 2009-02-23, Akihiro MOTOKI, LDP v3.19
.\"
.TH EPOLL 7 2009-02-01 "Linux" "Linux Programmer's Manual"
.\"O .SH NAME
.SH ̾Á°
.\"O epoll \- I/O event notification facility
epoll \- I/O ¥¤¥Ù¥ó¥ÈÄÌÃε¡Ç½
.\"O .SH SYNOPSIS
.SH ½ñ¼°
.B #include <sys/epoll.h>
.\"O .SH DESCRIPTION
.SH ÀâÌÀ
.\"O .B epoll
.\"O is a variant of
.\"O .BR poll (2)
.\"O that can be used either as an edge-triggered or a level-triggered
.\"O interface and scales well to large numbers of watched file descriptors.
.\"O The following system calls are provided to
.\"O create and manage an
.\"O .B epoll
.\"O instance:
.B epoll
¤Ï
.BR poll (2)
¤Î°ì¼ï¤Ç¤¢¤ê¡¢¥¨¥Ã¥¸¥È¥ê¥¬¥¤¥ó¥¿¥Õ¥§¡¼¥¹¤È
¥ì¥Ù¥ë¥È¥ê¥¬¥¤¥ó¥¿¥Õ¥§¡¼¥¹¤Î¤É¤Á¤é¤È¤·¤Æ¤â»ÈÍѤ¹¤ë¤³¤È¤¬¤Ç¤­¡¢
´Æ»ë¤¹¤ë¥Õ¥¡¥¤¥ë¥Ç¥£¥¹¥¯¥ê¥×¥¿¤Î¿ô¤¬Â¿¤¤¾ì¹ç¤Ë¤â»ÈÍѤǤ­¤ë¡£
.B epoll
¥¤¥ó¥¹¥¿¥ó¥¹¤ÎºîÀ®¤ä´ÉÍý¤ò¹Ô¤¦¤¿¤á¤Ë
°Ê²¼¤Î¥·¥¹¥Æ¥à¥³¡¼¥ë¤¬Ä󶡤µ¤ì¤Æ¤¤¤ë:
.IP * 3
.\"O An
.\"O .B epoll
.\"O instance created by
.\"O .BR epoll_create (2),
.\"O which returns a file descriptor referring to the epoll instance.
.\"O (The more recent
.\"O .BR epoll_create1 (2)
.\"O extends the functionality of
.\"O .BR epoll_create (2).)
.B epoll
¥¤¥ó¥¹¥¿¥ó¥¹¤Ï
.BR epoll_create (2)
¤ÇºîÀ®¤µ¤ì¤ë¡£
.BR epoll_create (2)
¤ÏºîÀ®¤·¤¿ epoll ¥¤¥ó¥¹¥¿¥ó¥¹¤ò»²¾È¤¹¤ë¥Õ¥¡¥¤¥ë¥Ç¥£¥¹¥¯¥ê¥×¥¿¤òÊÖ¤¹¡£
(¤â¤Ã¤È¿·¤·¤¤
.BR epoll_create1 (2)
¤Ç¤Ï¡¢
.BR epoll_create (2)
¤Îµ¡Ç½¤¬³ÈÄ¥¤µ¤ì¤Æ¤¤¤ë)¡£
.IP *
.\"O Interest in particular file descriptors is then registered via
.\"O .BR epoll_ctl (2).
ÆÃÄê¤Î¥Õ¥¡¥¤¥ë¥Ç¥£¥¹¥¯¥ê¥×¥¿¤ËÂФ¹¤ë´Æ»ëÆâÍƤò
.BR epoll_ctl (2)
¤ÇÅÐÏ¿¤¹¤ë¡£
.\"O The set of file descriptors currently registered on an
.\"O .B epoll
.\"O instance is sometimes called an
.\"O .I epoll
.\"O set.
.B epoll
¥¤¥ó¥¹¥¿¥ó¥¹¤Ë¸½ºßÅÐÏ¿¤µ¤ì¤Æ¤¤¤ë¥Õ¥¡¥¤¥ë¥Ç¥£¥¹¥¯¥ê¥×¥¿¤Î½¸¹ç¤Ï
.I epoll
½¸¹ç¤È¸Æ¤Ð¤ì¤ë¤³¤È¤â¤¢¤ë¡£
.IP *
.\"O Finally, the actual wait is started by
.\"O .BR epoll_wait (2).
ºÇ¸å¤Ë
.BR epoll_wait (2)
¤Ç¼ÂºÝ¤Î¥¤¥Ù¥ó¥ÈÂÔ¤Á¤ò³«»Ï¤¹¤ë¡£
.\"O .SS Level-Triggered and Edge-Triggered
.SS ¥ì¥Ù¥ë¥È¥ê¥¬¤È¥¨¥Ã¥¸¥È¥ê¥¬
.\"O The
.\"O .B epoll
.\"O event distribution interface is able to behave both as edge-triggered
.\"O (ET) and as level-triggered (LT).
.\"O The difference between the two mechanisms
.\"O can be described as follows.
.\"O Suppose that
.\"O this scenario happens:
.B epoll
¥¤¥Ù¥ó¥ÈÇÛÁ÷ (distribution) ¥¤¥ó¥¿¥Õ¥§¡¼¥¹¤Ï¡¢
¥¨¥Ã¥¸¥È¥ê¥¬ (ET) ¤È¤·¤Æ¤â¥ì¥Ù¥ë¥È¥ê¥¬ (LT) ¤È¤·¤Æ¤âÆ°ºî¤µ¤»¤ë¤³¤È¤¬¤Ç¤­¤ë¡£
Æó¤Ä¤ÎÇÛÁ÷µ¡¹½¤Î°ã¤¤¤Ï¡¢¼¡¤Î¤è¤¦¤ËÀâÌÀ¤Ç¤­¤ë¡£
¤³¤Î¤è¤¦¤Ê¥·¥Ê¥ê¥ª¤¬µ¯¤³¤Ã¤¿¤È¤·¤è¤¦:
.IP 1. 3
.\"O The file descriptor that represents the read side of a pipe
.\"O .RI ( rfd )
.\"O is registered on the
.\"O .B epoll
.\"O instance.
¥Ñ¥¤¥×¤ÎÆɤ߹þ¤ß¦¤òɽ¤¹¥Õ¥¡¥¤¥ë¥Ç¥£¥¹¥¯¥ê¥×¥¿
.RI ( rfd )
¤¬
.B epoll
¥¤¥ó¥¹¥¿¥ó¥¹¤ËÅÐÏ¿¤µ¤ì¤ë¡£
.IP 2.
.\"O A pipe writer writes 2 kB of data on the write side of the pipe.
¥Ñ¥¤¥×¤Ø½ñ¤­¹þ¤à¥×¥í¥°¥é¥à¤¬ 2 kB ¤Î¥Ç¡¼¥¿¤ò¥Ñ¥¤¥×¤Î½ñ¤­¹þ¤ß¦¤Ø½ñ¤­¹þ¤à¡£
.IP 3.
.\"O A call to
.\"O .BR epoll_wait (2)
.\"O is done that will return
.\"O .I rfd
.\"O as a ready file descriptor.
.BR epoll_wait (2)
¤ò¸Æ¤Ó½Ð¤¹¤È¡¢Æɤ߹þ¤ß²Äǽ (ready) ¤Ê¥Õ¥¡¥¤¥ë¥Ç¥£¥¹¥¯¥ê¥×¥¿¤È¤·¤Æ
.I rfd
¤¬Ê֤롣
.IP 4.
.\"O The pipe reader reads 1 kB of data from
.\"O .IR rfd .
¥Ñ¥¤¥×¤«¤éÆɤ߽Ф¹¥×¥í¥°¥é¥à¤¬¡¢1 kB ¤Î¥Ç¡¼¥¿¤ò
.I rfd
¤«¤éÆɤ߽Ф¹¡£
.IP 5.
.\"O A call to
.\"O .BR epoll_wait (2)
.\"O is done.
.BR epoll_wait (2)
¤Î¸Æ¤Ó½Ð¤·¤¬¹Ô¤ï¤ì¤ë¡£
.PP
.\"O If the
.\"O .I rfd
.\"O file descriptor has been added to the
.\"O .B epoll
.\"O interface using the
.\"O .B EPOLLET
.\"O (edge-triggered)
.\"O flag, the call to
.\"O .BR epoll_wait (2)
.\"O done in step
.\"O .B 5
.\"O will probably hang despite the available data still present in the file
.\"O input buffer;
.\"O meanwhile the remote peer might be expecting a response based on the
.\"O data it already sent.
.\"O The reason for this is that edge-triggered mode only
.\"O delivers events when changes occur on the monitored file descriptor.
.I rfd
¥Õ¥¡¥¤¥ë¥Ç¥£¥¹¥¯¥ê¥×¥¿¤¬
.B EPOLLET
¥Õ¥é¥° (¥¨¥Ã¥¸¥È¥ê¥¬) ¤ò»È¤Ã¤Æ
.B epoll
¤ËÄɲ䵤ì¤Æ¤¤¤ë¤È¡¢
ÍøÍѲÄǽ¤Ê¥Ç¡¼¥¿¤¬¥Õ¥¡¥¤¥ëÆþÎϥХåե¡¤Ë¤Þ¤À¸ºß¤¹¤ë¤Ë¤â¤«¤«¤ï¤é¤º
¥¹¥Æ¥Ã¥×
.B 5
¤Î
.BR epoll_wait (2)
¤Î¸Æ¤Ó½Ð¤·¤Ç¥Ï¥ó¥°¤¹¤ë²ÄǽÀ­¤¬¤¢¤ë¡£
¤½¤Î°ìÊý¤Ç¡¢¥ê¥â¡¼¥È¤ÎÀܳÀè (peer) ¤Ï´û¤ËÁ÷¤é¤ì¤¿¥Ç¡¼¥¿¤Ë
´ð¤Å¤¤¤Æ±þÅú¤ò´üÂÔ¤·¤Æ¤¤¤ë¤«¤â¤·¤ì¤Ê¤¤¡£
¤³¤Î¤è¤¦¤Ê¤³¤È¤¬µ¯¤³¤ëÍýͳ¤Ï¡¢¥¨¥Ã¥¸¥È¥ê¥¬¥¤¥Ù¥ó¥ÈÇÛÁ÷¤Ç¤Ï¡¢
¥â¥Ë¥¿¤·¤Æ¤¤¤ë¥Õ¥¡¥¤¥ë¤Ç¥¤¥Ù¥ó¥È¤¬µ¯¤Ã¤¿¤È¤­¤Ë¤Î¤ß¥¤¥Ù¥ó¥È¤¬
ÇÛÁ÷¤µ¤ì¤ë¤¿¤á¤Ç¤¢¤ë¡£
.\"O So, in step
.\"O .B 5
.\"O the caller might end up waiting for some data that is already present inside
.\"O the input buffer.
¤·¤¿¤¬¤Ã¤Æ¡¢¥¹¥Æ¥Ã¥×
.B 5
¤Ç¤Ï¡¢¸Æ¤Ó½Ð¤·Â¦¤Ï·ë²ÌŪ¤Ë
ÆþÎϥХåե¡Æâ¤Ë¤¹¤Ç¸ºß¤¹¤ë¥Ç¡¼¥¿¤òÂԤĤ³¤È¤Ë¤Ê¤ë¤«¤â¤·¤ì¤Ê¤¤¡£
.\"O In the above example, an event on
.\"O .I rfd
.\"O will be generated because of the write done in
.\"O .B 2
.\"O and the event is consumed in
.\"O .BR 3 .
¾åµ­¤ÎÎã¤Ç¤Ï¡¢
.B 2
¤Ç¹Ô¤ï¤ì¤¿½ñ¤­¹þ¤ß¤Ë¤è¤Ã¤Æ
.I rfd
¤Ë´Ø¤¹¤ë¥¤¥Ù¥ó¥È¤¬À¸À®¤µ¤ì¡¢
.B 3
¤Ç¥¤¥Ù¥ó¥È¤¬¾ÃÈñ (consume) ¤µ¤ì¤ë¡£
.\"O Since the read operation done in
.\"O .B 4
.\"O does not consume the whole buffer data, the call to
.\"O .BR epoll_wait (2)
.\"O done in step
.\"O .B 5
.\"O might block indefinitely.
.B 4
¤Ç¹Ô¤ï¤ì¤ëÆɤ߹þ¤ßÁàºî¤Ç¤Ï¡¢Á´Éô¤Î¥Ð¥Ã¥Õ¥¡¥Ç¡¼¥¿¤ò¾ÃÈñ¤·¤Ê¤¤¤Î¤Ç¡¢
¥¹¥Æ¥Ã¥×
.B 5
¤Ç¹Ô¤ï¤ì¤ë
.BR epoll_wait (2)
¤Î¸Æ¤Ó½Ð¤·¤¬
̵´ü¸Â¤ËÄä»ß (block) ¤¹¤ë¤«¤â¤·¤ì¤Ê¤¤¡£

.\"O An application that employs the
.\"O .B EPOLLET
.\"O flag should use nonblocking file descriptors to avoid having a blocking
.\"O read or write starve a task that is handling multiple file descriptors.
.B EPOLLET
¥Õ¥é¥°¤òºÎÍѤ¹¤ë¥¢¥×¥ê¥±¡¼¥·¥ç¥ó¤Ç¤Ï¡¢
¥¤¥ó¥¿¥Õ¥§¡¼¥¹¤Ï¥Ö¥í¥Ã¥¯¤·¤Ê¤¤ (nonblocking) ¥Õ¥¡¥¤¥ë¥Ç¥£¥¹¥¯¥ê¥×¥¿¤ò
»È¤¦¤Ù¤­¤Ç¤¢¤ë¡£
¤³¤ì¤Ï¡¢¥Ö¥í¥Ã¥¯¤µ¤ì¤ëÆɤ߹þ¤ß¤ä½ñ¤­¹þ¤ß¤Ë¤è¤Ã¤Æ¡¢
Ê£¿ô¤Î¥Õ¥¡¥¤¥ë¥Ç¥£¥¹¥¯¥ê¥×¥¿¤ò°·¤¦¥¿¥¹¥¯¤¬
Ää»ß¤·¤Æ¤·¤Þ¤¦¤Î¤òÈò¤±¤ë¤¿¤á¤Ç¤¢¤ë¡£
.\"O The suggested way to use
.\"O .B epoll
.\"O as an edge-triggered
.\"O .RB ( EPOLLET )
.\"O interface is as follows:
.B epoll
¤ò¥¨¥Ã¥¸¥È¥ê¥¬
.RB ( EPOLLET )
¥¤¥ó¥¿¥Õ¥§¡¼¥¹¤È¤·¤Æ»È¤¦¤¿¤á¤ËÄó°Æ¤µ¤ì¤ëÊýË¡¤Ï°Ê²¼¤ÎÄ̤ê¤Ç¤¢¤ë¡£
.RS
.TP 4
.B i
.\"O with nonblocking file descriptors; and
¥Ö¥í¥Ã¥¯¤·¤Ê¤¤¥Õ¥¡¥¤¥ë¥Ç¥£¥¹¥¯¥ê¥×¥¿¤È¶¦¤Ë»È¤¦¡£
.TP
.B ii
.\"O by waiting for an event only after
.\"O .BR read (2)
.\"O or
.\"O .BR write (2)
.\"O return
.\"O .BR EAGAIN .
.BR read (2)
¤Þ¤¿¤Ï
.BR write (2)
¤¬
.B EAGAIN
¤òÊÖ¤·¤¿¸å¤Ç¤Î¤ß¡¢¥¤¥Ù¥ó¥È¤òÂԤġ£
.RE
.PP
.\"O By contrast, when used as a level-triggered interface
.\"O (the default, when
.\"O .B EPOLLET
.\"O is not specified),
.\"O .B epoll
.\"O is simply a faster
.\"O .BR poll (2),
.\"O and can be used wherever the latter is used since it shares the
.\"O same semantics.
°ìÊý¡¢¥ì¥Ù¥ë¥È¥ê¥¬¥¤¥ó¥¿¥Õ¥§¡¼¥¹¤È¤·¤Æ»È¤¦¾ì¹ç
 (¤³¤Á¤é¤¬¥Ç¥Õ¥©¥ë¥È¤Ç¤¢¤ë¡¢
.B EPOLLET
¤¬»ØÄꤵ¤ì¤Ê¤«¤Ã¤¿¾ì¹ç)¡¢
.B epoll
¤Ïñ¤Ë¹â®¤Ê
.BR poll (2)
¤Ç¤¢¤ê¡¢»È¤¤Êý¤¬Æ±¤¸¤Ê¤Î¤Ç¡¢
.BR poll (2)
¤¬»È¤ï¤ì¤Æ¤¤¤ë¤È¤³¤í¤Ç¤Ï¤É¤³¤Ç¤â»ÈÍѤ¹¤ë¤³¤È¤¬¤Ç¤­¤ë¡£

.\"O Since even with edge-triggered
.\"O .BR epoll ,
.\"O multiple events can be generated upon receipt of multiple chunks of data,
.\"O the caller has the option to specify the
.\"O .B EPOLLONESHOT
.\"O flag, to tell
.\"O .B epoll
.\"O to disable the associated file descriptor after the receipt of an event with
.\"O .BR epoll_wait (2).
¥¨¥Ã¥¸¥È¥ê¥¬¤ò»È¤Ã¤¿¾ì¹ç¤Ç¤â¡¢Ê£¿ô¤Î¥Ç¡¼¥¿¤ò¼õ¿®¤¹¤ë¤ÈÊ£¿ô¤Î
.B epoll
¥¤¥Ù¥ó¥È¤¬À¸À®¤µ¤ì¤ë¤Î¤Ç¡¢
¸Æ¤Ó½Ð¤·Â¦¤Ë¤Ï
.B EPOLLONESHOT
¥Õ¥é¥°¤ò»ØÄꤹ¤ë¥ª¥×¥·¥ç¥ó¤¬¤¢¤ë¡£
¤³¤Î¥Õ¥é¥°¤Ï
.B epoll
¤ËÂФ·¤Æ¡¢
.BR epoll_wait (2)
¤Ë¤è¤ë¥¤¥Ù¥ó¥È¤ò¼õ¿®¤·¤¿¸å¤Ç¡¢´ØÏ¢¤¹¤ë¥Õ¥¡¥¤¥ë¥Ç¥£¥¹¥¯¥ê¥×¥¿¤ò̵¸ú¤Ë¤µ¤»¤ë¡£
.\"O When the
.\"O .B EPOLLONESHOT
.\"O flag is specified,
.\"O it is the caller's responsibility to rearm the file descriptor using
.\"O .BR epoll_ctl (2)
.\"O with
.\"O .BR EPOLL_CTL_MOD .
.B EPOLLONESHOT
¥Õ¥é¥°¤¬»ØÄꤵ¤ì¤¿¾ì¹ç¡¢
.BR epoll_ctl (2)
¤Ë
.B EPOLL_CTL_MOD
¤ò»ØÄꤷ¤Æ¥Õ¥¡¥¤¥ë¥Ç¥£¥¹¥¯¥ê¥×¥¿¤òºÆÅÙ»ÈÍѤǤ­¤ë¤è¤¦¤Ë¤¹¤ë¤Î¤Ï¡¢
¸Æ¤Ó½Ð¤·Â¦¤ÎÀÕǤ¤Ç¤¢¤ë¡£
.\"O .SS /proc interfaces
.SS /proc ¥¤¥ó¥¿¥Õ¥§¡¼¥¹
.\"O The following interfaces can be used to limit the amount of
.\"O kernel memory consumed by epoll:
epoll ¤¬¾ÃÈñ¤¹¤ë¥«¡¼¥Í¥ë¥á¥â¥ê¤ÎÎ̤òÀ©¸Â¤¹¤ë¤¿¤á¤Ë¡¢
°Ê²¼¤Î¥¤¥ó¥¿¥Õ¥§¡¼¥¹¤ò»ÈÍѤ¹¤ë¤³¤È¤¬¤Ç¤­¤ë¡£
.TP
.\" Following was added in 2.6.28, but them removed in 2.6.29
.\" .TP
.\" .IR /proc/sys/fs/epoll/max_user_instances " (since Linux 2.6.28)"
.\" This specifies an upper limit on the number of epoll instances
.\" that can be created per real user ID.
.TP
.\"O .IR /proc/sys/fs/epoll/max_user_watches " (since Linux 2.6.28)"
.IR /proc/sys/fs/epoll/max_user_watches " (Linux 2.6.28 °Ê¹ß)"
.\"O This specifies a limit on the total number of
.\"O file descriptors that a user can register across
.\"O all epoll instances on the system.
.\"O The limit is per real user ID.
.\"O Each registered file descriptor costs roughly 90 bytes on a 32-bit kernel,
.\"O and roughly 160 bytes on a 64-bit kernel.
.\"O Currently,
¤³¤Î¥Õ¥¡¥¤¥ë¤Ï¡¢¤¢¤ë¥æ¡¼¥¶¤¬¥·¥¹¥Æ¥à¾å¤ÎÁ´¤Æ¤Î epoll ¥¤¥ó¥¹¥¿¥ó¥¹¤Ë
ÅÐÏ¿¤Ç¤­¤ë¥Õ¥¡¥¤¥ë¥Ç¥£¥¹¥¯¥ê¥×¥¿¤ÎÁí¿ô¤Î¾å¸Â¤òµ¬Äꤹ¤ë¡£
¤³¤Î¾å¸Â¤Ï¼Â¥æ¡¼¥¶ ID ñ°Ì¤Ç¤¢¤ë¡£
ÅÐÏ¿¤µ¤ì¤¿¥Õ¥¡¥¤¥ë¥Ç¥£¥¹¥¯¥ê¥×¥¿ 1 ¤Ä¤¬¾ÃÈñ¤¹¤ë¥á¥â¥êÎ̤ϡ¢
32 ¥Ó¥Ã¥È¥«¡¼¥Í¥ë¤Ç¤ª¤è¤½ 90 ¥Ð¥¤¥È¡¢
64 ¥Ó¥Ã¥È¥«¡¼¥Í¥ë¤Ç¤ª¤è¤½ 160 ¥Ð¥¤¥È¤Ç¤¢¤ë¡£
.\" 2.6.29 (in 2.6.28, the default was 1/32 of lowmem)
.\"O the default value for
.\"O .I max_user_watches
.\"O is 1/25 (4%) of the available low memory,
.\"O divided by the registration cost in bytes.
.\"O motoki: low memory ¤ÎÌõ¤Ë¼«¿®¤Ê¤·¡£
¸½ºß¤Î¤È¤³¤í¡¢
.I max_user_watches
¤Î¥Ç¥Õ¥©¥ë¥ÈÃͤϡ¢ÍøÍѲÄǽ¤Ê¥á¥â¥ê²¼¸Â¤Î 1/25 (4%) ¤Ç¤¢¤ê¡¢
ÅÐÏ¿¤Ç¾ÃÈñ¤µ¤ì¤ë¥á¥â¥êÎÌ (¥Ð¥¤¥Èñ°Ì) ¤Ç³ä¤Ã¤¿ÃͤȤʤ롣
.\"O .SS Example for Suggested Usage
.SS ¤ª¤¹¤¹¤á¤Ê»ÈÍÑÎã
.\"O While the usage of
.\"O .B epoll
.\"O when employed as a level-triggered interface does have the same
.\"O semantics as
.\"O .BR poll (2),
.\"O the edge-triggered usage requires more clarification to avoid stalls
.\"O in the application event loop.
¥ì¥Ù¥ë¥È¥ê¥¬¥¤¥ó¥¿¥Õ¥§¡¼¥¹¤È¤·¤Æ»ÈÍѤ¹¤ë¤È¤­¤Î
.B epoll
¤Î»È¤¤Êý¤Ï
.BR poll (2)
¤ÈƱ¤¸¤Ç¤¢¤ë¡£
¤·¤«¤·¥¨¥Ã¥¸¥È¥ê¥¬¤È¤·¤Æ»È¤¦¾ì¹ç¤Ï¡¢
¥¢¥×¥ê¥±¡¼¥·¥ç¥ó¤Î¥¤¥Ù¥ó¥È¥ë¡¼¥×¤Ç¥¹¥È¡¼¥ë (stall) ¤·¤Ê¤¤¤è¤¦¤Ë¡¢
»È¤¤Êý¤ò¤è¤êÌÀ³Î¤Ë¤·¤Æ¤ª¤¯É¬Íפ¬¤¢¤ë¡£
.\"O In this example, listener is a
.\"O nonblocking socket on which
.\"O .BR listen (2)
.\"O has been called.
.\"O The function
.\"O .I do_use_fd()
.\"O uses the new ready file descriptor until
.\"O .B EAGAIN
.\"O is returned by either
.\"O .BR read (2)
.\"O or
.\"O .BR write (2).
¤³¤ÎÎã¤Ç¤Ï¡¢¥ê¥¹¥Ê¤Ï¥Ö¥í¥Ã¥¯¤·¤Ê¤¤¥½¥±¥Ã¥È¤Ç¤¢¤ê¡¢
.BR listen (2)
¤¬¸Æ¤Ð¤ì¤Æ¤¤¤ë¡£
´Ø¿ô
.I do_use_fd()
¤Ï¡¢
.BR read (2)
¤Þ¤¿¤Ï
.BR write (2)
¤Ë¤è¤Ã¤Æ
.B EAGAIN
¤¬ÊÖ¤µ¤ì¤ë¤Þ¤Ç¤Ï¡¢¿·¤·¤¤½àÈ÷ºÑ¤ß¤Î¥Õ¥¡¥¤¥ë¥Ç¥£¥¹¥¯¥ê¥×¥¿¤ò»È¤¦¡£
.\"O An event-driven state machine application should, after having received
.\"O .BR EAGAIN ,
.\"O record its current state so that at the next call to
.\"O .I do_use_fd()
.\"O it will continue to
.\"O .BR read (2)
.\"O or
.\"O .BR write (2)
.\"O from where it stopped before.
¥¤¥Ù¥ó¥È¶îÆ°¥¹¥Æ¡¼¥È¥Þ¥·¥ó¥¢¥×¥ê¥±¡¼¥·¥ç¥ó¤Ï¡¢
.B EAGAIN
¤ò¼õ¿®¤·¤¿¸å¡¢¥«¥ì¥ó¥È¤Î¾õÂÖ¤òµ­Ï¿¤·¤Æ¤ª¤¯¤Ù¤­¤Ç¤¢¤ë¡£
¤³¤ì¤Ë¤è¤ê¡¢¼¡¤Î
.I do_use_fd()
¸Æ¤Ó½Ð¤·¤Î¤È¤­¤Ë¡¢°ÊÁ°¤ËÄä»ß¤·¤¿¤È¤³¤í¤«¤é
.BR read (2)
¤Þ¤¿¤Ï
.BR write (2)
¤ò·Ñ³¤¹¤ë¤³¤È¤¬¤Ç¤­¤ë¡£

.in +4n
.nf
#define MAX_EVENTS 10
struct epoll_event ev, events[MAX_EVENTS];
int listen_sock, conn_sock, nfds, epollfd;

/* Set up listening socket, \(aqlisten_sock\(aq (socket(),
   bind(), listen()) */

epollfd = epoll_create(10);
if (epollfd == \-1) {
    perror("epoll_create");
    exit(EXIT_FAILURE);
}

ev.events = EPOLLIN;
ev.data.fd = listen_sock;
if (epoll_ctl(epollfd, EPOLL_CTL_ADD, listen_sock, &ev) == \-1) {
    perror("epoll_ctl: listen_sock");
    exit(EXIT_FAILURE);
}

for (;;) {
    nfds = epoll_wait(epollfd, events, MAX_EVENTS, \-1);
    if (nfds == \-1) {
        perror("epoll_pwait");
        exit(EXIT_FAILURE);
    }

    for (n = 0; n < nfds; ++n) {
        if (events[n].data.fd == listen_sock) {
            conn_sock = accept(listen_sock,
                            (struct sockaddr *) &local, &addrlen);
            if (conn_sock == \-1) {
                perror("accept");
                exit(EXIT_FAILURE);
            }
            setnonblocking(conn_sock);
            ev.events = EPOLLIN | EPOLLET;
            ev.data.fd = conn_sock;
            if (epoll_ctl(epollfd, EPOLL_CTL_ADD, conn_sock,
                        &ev) == \-1) {
                perror("epoll_ctl: conn_sock");
                exit(EXIT_FAILURE);
            }
        } else {
            do_use_fd(events[n].data.fd);
        }
    }
}
.fi
.in

.\"O When used as an edge-triggered interface, for performance reasons, it is
.\"O possible to add the file descriptor inside the
.\"O .B epoll
.\"O interface
.\"O .RB ( EPOLL_CTL_ADD )
.\"O once by specifying
.\"O .RB ( EPOLLIN | EPOLLOUT ).
.\"O This allows you to avoid
.\"O continuously switching between
.\"O .B EPOLLIN
.\"O and
.\"O .B EPOLLOUT
.\"O calling
.\"O .BR epoll_ctl (2)
.\"O with
.\"O .BR EPOLL_CTL_MOD .
¥¨¥Ã¥¸¥È¥ê¥¬¥¤¥ó¥¿¥Õ¥§¡¼¥¹¤È¤·¤Æ»È¤¦¾ì¹ç¡¢À­Ç½¾å¤ÎÍýͳ¤Ë¤è¤ê¡¢
°ìÅÙ
.RB ( EPOLLIN | EPOLLOUT )
¤ò»ØÄꤷ¤Æ¤«¤é
.RB ( EPOLL_CTL_ADD
¤Ç) ¥Õ¥¡¥¤¥ë¥Ç¥£¥¹¥¯¥ê¥×¥¿¤ò
.B epoll
¥¤¥ó¥¿¥Õ¥§¡¼¥¹¤ËÄɲ乤뤳¤È¤¬¤Ç¤­¤ë¡£
¤³¤ì¤Ë¤è¤ê¡¢
.BR epoll_ctl (2)
¤Ë
.B EPOLL_CTL_MOD
¤ò»ØÄꤷ¤Æ¸Æ¤Ó½Ð¤¹¤³¤È¤Ç
.B EPOLLIN
¤È
.B EPOLLOUT
¤ÎϢ³Ū¤ÊÀÚ¤êÂؤ¨¤¬Èò¤±¤é¤ì¤ë¡£
.\"O .SS Questions and Answers
.SS ¼ÁÌä¤È²òÅú
.TP 4
.B Q0
.\"O What is the key used to distinguish the file descriptors registered in an
.\"O .B epoll
.\"O set?
.B epoll
½¸¹çÆâ¤ÎÅÐÏ¿¤µ¤ì¤¿¥Õ¥¡¥¤¥ë¥Ç¥£¥¹¥¯¥ê¥×¥¿¤ò¶èÊ̤¹¤ë¤Ë¤Ï¡¢
²¿¤ò¥­¡¼¤È¤·¤Æ»È¤¨¤Ð¤è¤¤¤«¡©
.TP
.B A0
.\"O The key is the combination of the file descriptor number and
.\"O the open file description
.\"O (also known as an "open file handle",
.\"O the kernel's internal representation of an open file).
¥­¡¼¤Ï¥Õ¥¡¥¤¥ë¥Ç¥£¥¹¥¯¥ê¥×¥¿ÈÖ¹æ¤È¥ª¡¼¥×¥ó¥Õ¥¡¥¤¥ëµ­½Ò (open file
description) ¤ÎÁȤǤ¢¤ë (¥ª¡¼¥×¥ó¥Õ¥¡¥¤¥ëµ­½Ò¤Ï "open file handle" ¤È¤â
¸Æ¤Ð¤ì¡¢¥ª¡¼¥×¥ó¤µ¤ì¤¿¥Õ¥¡¥¤¥ë¤Î¥«¡¼¥Í¥ë¤ÎÆâÉôɽ¸½¤Ç¤¢¤ë)¡£
.TP
.B Q1
.\"O What happens if you register the same file descriptor on an
.\"O .B epoll
.\"O instance twice?
1 ¤Ä¤Î
.B epoll
¥¤¥ó¥¹¥¿¥ó¥¹¤ËƱ¤¸¥Õ¥¡¥¤¥ë¥Ç¥£¥¹¥¯¥ê¥×¥¿¤ò 2 ²óÅÐÏ¿¤¹¤ë¤È¤É¤¦¤Ê¤ë¤«¡©
.TP
.B A1
.\"O You will probably get
.\"O .BR EEXIST .
.\"O However, it is possible to add a duplicate
.\"O .RB ( dup (2),
.\"O .BR dup2 (2),
.\"O .BR fcntl (2)
.\"O .BR F_DUPFD )
.\"O descriptor to the same
.\"O .B epoll
.\"O instance.
¤¿¤Ö¤ó
.B EEXIST
¤ò¼õ¤±¼è¤ë¤À¤í¤¦¡£
¤·¤«¤·¤Ê¤¬¤é¡¢Æ±¤¸
.B epoll
¥¤¥ó¥¹¥¿¥ó¥¹¤ËÂФ·¤ÆÊ£À½¤µ¤ì¤¿¥Ç¥£¥¹¥¯¥ê¥×¥¿¤òÄɲ乤뤳¤È¤Ï²Äǽ¤Ç¤¢¤ë
.RB ( dup (2),
.BR dup2 (2),
.BR fcntl (2)
.B F_DUPFD
¤Ê¤É)¡£
.\" But a descriptor duplicated by fork(2) can't be added to the
.\" set, because the [file *, fd] pair is already in the epoll set.
.\" That is a somewhat ugly inconsistency.  On the one hand, a child process
.\" cannot add the duplicate file descriptor to the epoll set.  (In every
.\" other case that I can think of, descriptors duplicated by fork have
.\" similar semantics to descriptors duplicated by dup() and friends.)  On
.\" the other hand, the very fact that the child has a duplicate of the
.\" descriptor means that even if the parent closes its descriptor, then
.\" epoll_wait() in the parent will continue to receive notifications for
.\" that descriptor because of the duplicated descriptor in the child.
.\"
.\" See http://thread.gmane.org/gmane.linux.kernel/596462/
.\" "epoll design problems with common fork/exec patterns"
.\"
.\" mtk, Feb 2008
.\"O This can be a useful technique for filtering events,
.\"O if the duplicate file descriptors are registered with different
.\"O .I events
.\"O masks.
Ê£À½¤·¤¿¥Õ¥¡¥¤¥ë¥Ç¥£¥¹¥¯¥ê¥×¥¿¤ò°Û¤Ê¤ë
.I events
¥Þ¥¹¥¯¤ÇÅÐÏ¿¤¹¤ì¤Ð¡¢¥¤¥Ù¥ó¥È¤ò¥Õ¥£¥ë¥¿¥ê¥ó¥°¤¹¤ë¤Î¤Ë
¤³¤Îµ¡Ç½¤ÏÍ­ÍѤʼêË¡¤Ç¤¢¤ë¡£
.TP
.B Q2
.\"O Can two
.\"O .B epoll
.\"O instances wait for the same file descriptor?
.\"O If so, are events reported to both
.\"O .B epoll
.\"O file descriptors?
2 ¤Ä¤Î
.B epoll
¥¤¥ó¥¹¥¿¥ó¥¹¤¬Æ±¤¸¥Õ¥¡¥¤¥ë¥Ç¥£¥¹¥¯¥ê¥×¥¿¤òÂÔ¤Á¼õ¤±¤ë¤³¤È¤Ï²Äǽ¤«¡©
¤â¤·²Äǽ¤Ç¤¢¤ì¤Ð¡¢¥¤¥Ù¥ó¥È¤ÏξÊý¤Î
.B epoll
¥Õ¥¡¥¤¥ë¥Ç¥£¥¹¥¯¥ê¥×¥¿¤ËÊó¹ð¤µ¤ì¤ë¤«¡©
.TP
.B A2
.\"O Yes, and events would be reported to both.
.\"O However, careful programming may be needed to do this correctly.
¥¤¥Ù¥ó¥È¤ÏξÊý¤ËÊó¹ð¤µ¤ì¤ë¡£
¤·¤«¤·¤Ê¤¬¤é¡¢¤³¤ì¤òÀµ¤·¤¯°·¤¦¤Ë¤ÏÃí°Õ¿¼¤¯¥×¥í¥°¥é¥ß¥ó¥°¤¹¤ëɬÍפ¬
¤¢¤ë¤«¤â¤·¤ì¤Ê¤¤¡£
.TP
.B Q3
.\"O Is the
.\"O .B epoll
.\"O file descriptor itself poll/epoll/selectable?
.B epoll
¥Õ¥¡¥¤¥ë¥Ç¥£¥¹¥¯¥ê¥×¥¿¼«¿È¤Ï poll/epoll/select ¤¬²Äǽ¤«¡©
.TP
.B A3
.\"O Yes.
.\"O If an
.\"O .B epoll
.\"O file descriptor has events waiting then it will
.\"O indicate as being readable.
²Äǽ¤Ç¤¢¤ë¡£
.B epoll
¥Õ¥¡¥¤¥ë¥Ç¥£¥¹¥¯¥ê¥×¥¿¤Ë½èÍýÂÔ¤Á¤Î¥¤¥Ù¥ó¥È¤¬¤¢¤ë¾ì¹ç¤Ï¡¢
Æɤ߽Ф·²Äǽ¤À¤ÈÄÌÃΤµ¤ì¤ë¤³¤È¤À¤í¤¦¡£
.TP
.B Q4
.\"O What happens if one attempts to put an
.\"O .B epoll
.\"O file descriptor into its own file descriptor set?
.B epoll
¥Õ¥¡¥¤¥ë¥Ç¥£¥¹¥¯¥ê¥×¥¿¤ò¼«¿È¤Î¥Õ¥¡¥¤¥ë¥Ç¥£¥¹¥¯¥ê¥×¥¿½¸¹ç¤Ë
Æþ¤ì¤è¤¦¤È¤¹¤ë¤È¤É¤¦¤Ê¤ë¤«¡©
.TP
.B A4
.\"O The
.\"O .BR epoll_ctl (2)
.\"O call will fail
.\"O .RB ( EINVAL ).
.\"O However, you can add an
.\"O .B epoll
.\"O file descriptor inside another
.\"O .B epoll
.\"O file descriptor set.
.BR epoll_ctl (2)
¤Î¸Æ¤Ó½Ð¤·¤Ï
.RB ( EINVAL
¤Ç) ¼ºÇÔ¤¹¤ë¤À¤í¤¦¡£
¤¿¤À¤·
.B epoll
¥Õ¥¡¥¤¥ë¥Ç¥£¥¹¥¯¥ê¥×¥¿¤ò¾¤Î
.B epoll
¥Õ¥¡¥¤¥ë¥Ç¥£¥¹¥¯¥ê¥×¥¿½¸¹ç¤ÎÆâÉô¤ËÄɲ乤뤳¤È¤Ï²Äǽ¤Ç¤¢¤ë¡£
.TP
.B Q5
.\"O Can I send an
.\"O .B epoll
.\"O file descriptor over a UNIX domain socket to another process?
.B epoll
¥Õ¥¡¥¤¥ë¥Ç¥£¥¹¥¯¥ê¥×¥¿¤ò UNIX ¥É¥á¥¤¥ó¥½¥±¥Ã¥È¤Ç¾¤Î¥×¥í¥»¥¹¤ËÁ÷¤ë¤³¤È¤Ï²Äǽ¤«¡©
.TP
.B A5
.\"O Yes, but it does not make sense to do this, since the receiving process
.\"O would not have copies of the file descriptors in the
.\"O .B epoll
.\"O set.
²Äǽ¤À¤¬¡¢¤³¤ì¤ò¤¹¤ë¤³¤È¤Ë°ÕÌ£¤Ï¤Ê¤¤¡£
¤Ê¤¼¤Ê¤é¡¢¼õ¿®Â¦¤Î¥×¥í¥»¥¹¤¬
.B epoll
½¸¹çÆâ¤Î¥Õ¥¡¥¤¥ë¥Ç¥£¥¹¥¯¥ê¥×¥¿¤Î¥³¥Ô¡¼¤ò»ý¤Ã¤Æ¤¤¤Ê¤¤¤«¤é¤Ç¤¢¤ë¡£
.TP
.B Q6
.\"O Will closing a file descriptor cause it to be removed from all
.\"O .B epoll
.\"O sets automatically?
¥Õ¥¡¥¤¥ë¥Ç¥£¥¹¥¯¥ê¥×¥¿¤ò¥¯¥í¡¼¥º¤¹¤ë¤È¡¢¤½¤Î¥Õ¥¡¥¤¥ë¥Ç¥£¥¹¥¯¥ê¥×¥¿¤ÏÁ´¤Æ¤Î
.B epoll
½¸¹ç¤«¤é¼«Æ°Åª¤Ëºï½ü¤µ¤ì¤ë¤«¡©
.TP
.B A6
.\"O Yes, but be aware of the following point.
ºï½ü¤µ¤ì¤ë¤¬¡¢°Ê²¼¤ÎÅÀ¤ËÃí°Õ¤¬É¬ÍפǤ¢¤ë¡£
.\"O A file descriptor is a reference to an open file description (see
.\"O .BR open (2)).
¥Õ¥¡¥¤¥ë¥Ç¥£¥¹¥¯¥ê¥×¥¿¤Ï¥ª¡¼¥×¥ó¥Õ¥¡¥¤¥ëµ­½Ò
.RB ( open (2)
»²¾È) ¤Ø¤Î»²¾È¤Ç¤¢¤ë¡£
.\"O Whenever a descriptor is duplicated via
.\"O .BR dup (2),
.\"O .BR dup2 (2),
.\"O .BR fcntl (2)
.\"O .BR F_DUPFD ,
.\"O or
.\"O .BR fork (2),
.\"O a new file descriptor referring to the same open file description is
.\"O created.
¥Ç¥£¥¹¥¯¥ê¥×¥¿¤ÎÊ£À½¤ò
.BR dup (2),
.BR dup2 (2),
.BR fcntl (2)
¤Î
.B F_DUPFD
¤ä
.BR fork (2)
·Ðͳ¤Ç¹Ô¤¦Å٤ˡ¢Æ±¤¸¥ª¡¼¥×¥ó¥Õ¥¡¥¤¥ëµ­½Ò¤ò»²¾È¤¹¤ë¿·µ¬¤Î¥Õ¥¡¥¤¥ë
¥Ç¥£¥¹¥¯¥ê¥×¥¿¤¬À¸À®¤µ¤ì¤ë¡£
.\"O An open file description continues to exist until all
.\"O file descriptors referring to it have been closed.
¥ª¡¼¥×¥ó¥Õ¥¡¥¤¥ëµ­½Ò¼«ÂΤϡ¢¼«¿È¤ò»²¾È¤¹¤ëÁ´¤Æ¤Î¥Õ¥¡¥¤¥ë¥Ç¥£¥¹¥¯¥ê¥×¥¿
¤¬¥¯¥í¡¼¥º¤µ¤ì¤ë¤Þ¤Ç¸ºß¤·Â³¤±¤ë¡£
.\"O A file descriptor is removed from an
.\"O .B epoll
.\"O set only after all the file descriptors referring to the underlying
.\"O open file description have been closed
.\"O (or before if the descriptor is explicitly removed using
.\"O .BR epoll_ctl ()
.\"O .BR EPOLL_CTL_DEL ).
¥Õ¥¡¥¤¥ë¥Ç¥£¥¹¥¯¥ê¥×¥¿¤¬
.B epoll
½¸¹ç¤«¤éºï½ü¤µ¤ì¤ë¤Î¤Ï¡¢Âбþ¤¹¤ë¥ª¡¼¥×¥ó¥Õ¥¡¥¤¥ëµ­½Ò¤ò»²¾È¤·¤Æ¤¤¤ë
Á´¤Æ¤Î¥Õ¥¡¥¤¥ë¥Ç¥£¥¹¥¯¥ê¥×¥¿¤¬¥¯¥í¡¼¥º¤µ¤ì¤¿¸å¤Ç¤¢¤ë
.RB ( epoll_ctl ()
.B EPOLL_CTL_DEL
¤ò»È¤Ã¤Æ¤½¤Î¥Ç¥£¥¹¥¯¥ê¥×¥¿¤òÌÀ¼¨Åª¤Ëºï½ü¤·¤¿¾ì¹ç¤Ë¤âºï½ü¤µ¤ì¤ë)¡£
.\"O This means that even after a file descriptor that is part of an
.\"O .B epoll
.\"O set has been closed,
.\"O events may be reported for that file descriptor if other file
.\"O descriptors referring to the same underlying file description remain open.
¤³¤Î¤³¤È¤Ï¡¢
.B epoll
½¸¹ç¤Ë°¤·¤Æ¤¤¤ë¤¢¤ë¥Õ¥¡¥¤¥ë¥Ç¥£¥¹¥¯¥ê¥×¥¿¤ò¥¯¥í¡¼¥º¤·¤¿¸å¤Ç¤¢¤Ã¤Æ¤â¡¢
Ʊ¤¸¥Õ¥¡¥¤¥ëµ­½Ò¤ò»²¾È¤¹¤ë¾¤Î¥Õ¥¡¥¤¥ë¥Ç¥£¥¹¥¯¥ê¥×¥¿¤¬¥ª¡¼¥×¥ó¤µ¤ì¤Æ¤¤¤ë´Ö¤Ï¡¢
¥¯¥í¡¼¥º¤·¤¿¥Õ¥¡¥¤¥ë¥Ç¥£¥¹¥¯¥ê¥×¥¿°¸¤Ë¥¤¥Ù¥ó¥È¤¬Êó¹ð¤µ¤ì¤ë²ÄǽÀ­¤¬¤¢¤ë¤È
¤¤¤¦¤³¤È¤ò°ÕÌ£¤¹¤ë¡£
.TP
.B Q7
.\"O If more than one event occurs between
.\"O .BR epoll_wait (2)
.\"O calls, are they combined or reported separately?
2 ¤Ä°Ê¾å¤Î¥¤¥Ù¥ó¥È¤¬
.BR epoll_wait (2)
¥³¡¼¥ë¤Î´Ö¤ËȯÀ¸¤·¤¿¾ì¹ç¡¢¤½¤ì¤é¤Ï¤Þ¤È¤á¤ÆÊó¹ð¤µ¤ì¤ë¤«¡¢
¤½¤ì¤È¤âÊÌ¡¹¤ËÊó¹ð¤µ¤ì¤ë¤«¡©
.TP
.B A7
.\"O They will be combined.
¤Þ¤È¤á¤ÆÊó¹ð¤µ¤ì¤ë¤À¤í¤¦¡£
.TP
.B Q8
.\"O Does an operation on a file descriptor affect the
.\"O already collected but not yet reported events?
¥Õ¥¡¥¤¥ë¥Ç¥£¥¹¥¯¥ê¥×¥¿¤ËÂФ¹¤ëÁàºî¤Ï¡¢
´û¤Ë½¸¤á¤é¤ì¤Æ¤¤¤ë¤¬¤Þ¤ÀÊó¹ð¤µ¤ì¤Æ¤¤¤Ê¤¤¥¤¥Ù¥ó¥È¤Ë±Æ¶Á¤¹¤ë¤«¡©
.TP
.B A8
.\"O You can do two operations on an existing file descriptor.
.\"O Remove would be meaningless for
.\"O this case.
.\"O Modify will reread available I/O.
´û¸¤Î¥Õ¥¡¥¤¥ë¥Ç¥£¥¹¥¯¥ê¥×¥¿¤ËÂФ·¤Æ 2 ¤Ä¤ÎÁàºî¤ò¹Ô¤¦¤³¤È¤¬¤Ç¤­¤ë¡£
¤³¤Î¾ì¹ç¡¢ºï½ü¤Ë¤Ï°ÕÌ£¤¬¤Ê¤¤¡£
Êѹ¹¤¹¤ë¤È¡¢»ÈÍѲÄǽ¤Ê I/O ¤¬ºÆ¤ÓÆɤ߹þ¤Þ¤ì¤ë¡£
.TP
.B Q9
.\"O Do I need to continuously read/write a file descriptor
.\"O until
.\"O .B EAGAIN
.\"O when using the
.\"O .B EPOLLET
.\"O flag (edge-triggered behavior) ?
.B EPOLLET
¥Õ¥é¥° (¥¨¥Ã¥¸¥È¥ê¥¬Æ°ºî) ¤ò»È¤Ã¤Æ¤¤¤ë¾ì¹ç¡¢
.B EAGAIN
¤ò¼õ¤±¼è¤ë¤Þ¤Ç¡¢
·Ñ³¤·¤Æ¥Õ¥¡¥¤¥ë¥Ç¥£¥¹¥¯¥ê¥×¥¿¤òÆɤ߽ñ¤­¤¹¤ëɬÍפ¬¤¢¤ë¤«¡©
.TP
.B A9
.\"O Receiving an event from
.\"O .BR epoll_wait (2)
.\"O should suggest to you that such
.\"O file descriptor is ready for the requested I/O operation.
.BR epoll_wait (2)
¤«¤é¥¤¥Ù¥ó¥È¤ò¼õ¤±¼è¤ë¤³¤È¤Ï¡¢
¤½¤Î¥Õ¥¡¥¤¥ë¥Ç¥£¥¹¥¯¥ê¥×¥¿¤¬Í׵ᤵ¤ì¤¿ I/O Áàºî¤ËÂФ·¤Æ½àÈ÷ºÑ¤ß¤Ç¤¢¤ë¡¢
¤È¤¤¤¦¤³¤È¤ò¥æ¡¼¥¶¤Ë¼¨¤¹¤â¤Î¤Ç¤¢¤ë¡£
.\"O You must consider it ready until the next (nonblocking)
.\"O read/write yields
.\"O .BR EAGAIN .
¼¡¤Î (¥Ö¥í¥Ã¥¯¤·¤Ê¤¤) read/write ¤Ç
.B EAGAIN
¤ò¼õ¤±¼è¤ë¤Þ¤Ç¤Ï¥Õ¥¡¥¤¥ë¥Ç¥£¥¹¥¯¥ê¥×¥¿¤Ï½àÈ÷ºÑ¤ß¤Ç¤¢¤ë¤È
¹Í¤¨¤Ê¤±¤ì¤Ð¤Ê¤é¤Ê¤¤¡£
.\"O When and how you will use the file descriptor is entirely up to you.
¤½¤Î¥Õ¥¡¥¤¥ë¥Ç¥£¥¹¥¯¥ê¥×¥¿¤ò¤¤¤Ä¤É¤Î¤è¤¦¤Ë»È¤¦¤«¤Ï¡¢
Á´¤¯¥æ¡¼¥¶¤ËǤ¤µ¤ì¤Æ¤ë¡£
.sp
.\"O For packet/token-oriented files (e.g., datagram socket,
.\"O terminal in canonical mode),
.\"O the only way to detect the end of the read/write I/O space
.\"O is to continue to read/write until
.\"O .BR EAGAIN .
¥Ñ¥±¥Ã¥È»Ø¸þ¤ä¥È¡¼¥¯¥ó»Ø¸þ¤Î¥Õ¥¡¥¤¥ë (Î㤨¤Ð¡¢¥Ç¡¼¥¿¥°¥é¥à¥½¥±¥Ã¥È¡¢
canonical ¥â¡¼¥É¤ÎüËö) ¤Ç¤Ï¡¢
Æɤ߹þ¤ßÍÑ / ½ñ¤­¹þ¤ßÍѤΠI/O ¶õ´Ö¤ÎËöÈø¤ò¸¡ÃΤ¹¤ëÍ£°ì¤ÎÊýË¡¤Ï
.B EAGAIN
¤Ë¤Ê¤ë¤Þ¤Ç read/write ¤ò¹Ô¤¦¤³¤È¤Ç¤¢¤ë¡£
.sp
.\"O For stream-oriented files (e.g., pipe, FIFO, stream socket), the
.\"O condition that the read/write I/O space is exhausted can also be detected by
.\"O checking the amount of data read from / written to the target file
.\"O descriptor.
¥¹¥È¥ê¡¼¥à»Ø¸þ¤Î¥Õ¥¡¥¤¥ë (Î㤨¤Ð¡¢¥Ñ¥¤¥×¡¢FIFO¡¢¥¹¥È¥ê¡¼¥à¥½¥±¥Ã¥È) ¤Ç¤Ï¡¢
Æɤ߹þ¤ßÍÑ / ½ñ¤­¹þ¤ßÍѤΠI/O ¶õ´Ö¤¬»È¤¤¿Ô¤¯¤µ¤ì¤¿¾õÂ֤ϡ¢
ÂоݤȤʤë¥Õ¥¡¥¤¥ë¥Ç¥£¥¹¥¯¥ê¥×¥¿¤«¤éÆɤ߹þ¤ó¤À¥Ç¡¼¥¿Î̤ޤ¿¤Ï
½ñ¤­¹þ¤ó¤À¥Ç¡¼¥¿Î̤ò¥Á¥§¥Ã¥¯¤¹¤ë¤³¤È¤Ç¤â¸¡ÃΤǤ­¤ë¡£
.\"O For example, if you call
.\"O .BR read (2)
.\"O by asking to read a certain amount of data and
.\"O .BR read (2)
.\"O returns a lower number of bytes, you
.\"O can be sure of having exhausted the read I/O space for the file
.\"O descriptor.
.\"O The same is true when writing using
.\"O .BR write (2).
.\"O (Avoid this latter technique if you cannot guarantee that
.\"O the monitored file descriptor always refers to a stream-oriented file.)
Î㤨¤Ð¡¢¤¢¤ëÆÃÄê¤ÎÎ̤Υǡ¼¥¿¤òÆɤ߹þ¤à¤¿¤á¤Ë
.BR read (2)
¤ò¸Æ¤ó¤À¤È¤­¤Ë¡¢
.BR read (2)
¤¬ÊÖ¤·¤¿¥Ð¥¤¥È¿ô¤¬¤½¤ì¤è¤ê¾¯¤Ê¤«¤Ã¤¿¾ì¹ç¡¢
¤½¤Î¥Õ¥¡¥¤¥ë¥Ç¥£¥¹¥¯¥ê¥×¥¿¤ÎÆɤ߹þ¤ßÍÑ I/O ¶õ´Ö¤¬
»È¤¤¿Ô¤¯¤µ¤ì¤¿¤³¤È¤¬Ê¬¤«¤ë¡£
.BR write (2)
¤ò»È¤Ã¤Æ½ñ¤­¹þ¤ß¤ò¤¹¤ë¤È¤­¤â¡¢Æ±¤¸¤³¤È¤¬¸À¤¨¤ë
(´Æ»ë¤·¤Æ¤¤¤ë¥Õ¥¡¥¤¥ë¥Ç¥£¥¹¥¯¥ê¥×¥¿¤¬¾ï¤Ë¥¹¥È¥ê¡¼¥à»Ø¸þ¤Î¥Õ¥¡¥¤¥ë¤ò
»²¾È¤·¤Æ¤¤¤ë¤³¤È¤òÊݾڤǤ­¤Ê¤¤¾ì¹ç¤Ë¤Ï¡¢¸å¼Ô¤Î¼êË¡¤Î»ÈÍѤòÈò¤±¤ë¤³¤È)¡£
.\"O .SS Possible Pitfalls and Ways to Avoid Them
.SS ¤¢¤ê¤¬¤Á¤ÊÍî¤È¤··ê¤È²óÈòÊýË¡
.TP
.\"O .B o Starvation (edge-triggered)
.B o µ²²î (starvation) (¥¨¥Ã¥¸¥È¥ê¥¬)
.PP
.\"O If there is a large amount of I/O space,
.\"O it is possible that by trying to drain
.\"O it the other files will not get processed causing starvation.
.\"O (This problem is not specific to
.\"O .BR epoll .)
Â礭¤Ê I/O ¶õ´Ö¤¬¤¢¤ë¾ì¹ç¡¢
¤½¤Î I/O ¶õ´Ö¤Î¥Ç¡¼¥¿¤òÁ´¤Æ½èÍý (drain) ¤·¤è¤¦¤È¤¹¤ë¤È¡¢
¾¤Î¥Õ¥¡¥¤¥ë¤¬½èÍý¤µ¤ì¤º¡¢µ²²î¤òȯÀ¸¤µ¤»¤ë¤³¤È¤¬¤¢¤ë
(¤³¤ÎÌäÂê¤Ï
.B epoll
¤Ë¸ÇÍ­¤Î¤â¤Î¤Ç¤Ï¤Ê¤¤)¡£
.PP
.\"O The solution is to maintain a ready list
.\"O and mark the file descriptor as ready
.\"O in its associated data structure, thereby allowing the application to
.\"O remember which files need to be processed but still round robin amongst
.\"O all the ready files.
.\"O This also supports ignoring subsequent events you
.\"O receive for file descriptors that are already ready.
¤³¤ÎÌäÂê¤Î²ò·èË¡¤Ï¡¢½àÈ÷ºÑ¤ß¾õÂ֤Υꥹ¥È¤ò´ÉÍý¤·¤Æ¡¢
´ØÏ¢¤¹¤ë data ¹½Â¤ÂΤÎÃæ¤Ç¥Õ¥¡¥¤¥ë¥Ç¥£¥¹¥¯¥ê¥×¥¿¤¬
ÍøÍѲÄǽ¤Ç¤¢¤ë¤È¥Þ¡¼¥¯¤¹¤ë¤³¤È¤Ç¤¢¤ë¡£
¤½¤ì¤Ë¤è¤Ã¤Æ¡¢ÍøÍѲÄǽ¤Ê¤¹¤Ù¤Æ¤Î¥Õ¥¡¥¤¥ë¤ÎÃæ¤Ç
¤É¤Î¥Õ¥¡¥¤¥ë¤ò½èÍý¤¹¤ëɬÍפ¬¤¢¤ë¤«¤ò²±¤¨¤ë¤³¤È¤¬¤Ç¤­¡¢
¤·¤«¤â½çÈ֤˽èÍý (round robin) ¤¹¤ë¤³¤È¤¬¤Ç¤­¤ë¡£
´û¤ËÍøÍѲÄǽ¤Ç¤¢¤ë¥Õ¥¡¥¤¥ë¥Ç¥£¥¹¥¯¥ê¥×¥¿¤ËÂФ·¤Æ
¤½¤ì°Ê¸å¤Ë¼õ¤±¼è¤ë¥¤¥Ù¥ó¥È¤ò̵»ë¤¹¤ë¤³¤È¤â¤Ç¤­¤ë¡£
.TP
.\"O .B o If using an event cache...
.B o ¥¤¥Ù¥ó¥È¥­¥ã¥Ã¥·¥å¤ò»È¤Ã¤Æ¤¤¤ë¾ì¹ç
.PP
.\"O If you use an event cache or store all the file descriptors returned from
.\"O .BR epoll_wait (2),
.\"O then make sure to provide a way to mark
.\"O its closure dynamically (i.e., caused by
.\"O a previous event's processing).
.\"O Suppose you receive 100 events from
.\"O .BR epoll_wait (2),
.\"O and in event #47 a condition causes event #13 to be closed.
¥¤¥Ù¥ó¥È¥­¥ã¥Ã¥·¥å¤ò»È¤Ã¤Æ¤¤¤ë¾ì¹ç¡¢
¤Þ¤¿¤Ï
.BR epoll_wait (2)
¤«¤éÊÖ¤µ¤ì¤¿Á´¤Æ¤Î¥Õ¥¡¥¤¥ë¥Ç¥£¥¹¥¯¥ê¥×¥¿¤ò³ÊǼ¤·¤Æ¤¤¤ë¾ì¹ç¡¢
¥¯¥í¡¼¥º¤µ¤ì¤¿¤³¤È¤òưŪ¤Ë¥Þ¡¼¥¯¤¹¤ë
(¤Ä¤Þ¤êÁ°¤Î¥¤¥Ù¥ó¥È¤Î½èÍý¤Ë¤è¤Ã¤Æ¥Þ¡¼¥¯¤µ¤ì¤ë) ÊýË¡¤òÄ󶡤¹¤Ù¤­¤Ç¤¢¤ë¡£
.BR epoll_wait (2)
¤«¤é 100 ¸Ä¤Î¥¤¥Ù¥ó¥È¤ò¼õ¤±¼è¤ê¡¢
¥¤¥Ù¥ó¥È #47 ¤Ç¤Ï¤¢¤ë¾ò·ï¤Ç¥¤¥Ù¥ó¥È #13 ¤¬ÊĤ¸¤é¤ì¤ë¤È²¾Äꤹ¤ë¡£
.\"O If you remove the structure and
.\"O .BR close (2)
.\"O the file descriptor for event #13, then your
.\"O event cache might still say there are events waiting for that
.\"O file descriptor causing confusion.
¥¤¥Ù¥ó¥È #13 ¤Î¹½Â¤ÂΤòºï½ü¤·¥Õ¥¡¥¤¥ë¥Ç¥£¥¹¥¯¥ê¥×¥¿¤ò
.BR close (2)
¤¹¤ë¤È¡¢¥¤¥Ù¥ó¥È¥­¥ã¥Ã¥·¥å¤Ï¤½¤Î¥Õ¥¡¥¤¥ë¥Ç¥£¥¹¥¯¥ê¥×¥¿¤òÂԤĥ¤¥Ù¥ó¥È¤¬
¸ºß¤¹¤ë¤È¤¤¤Ã¤Æ¡¢º®Í𤬵¯¤­¤ë¡£
.PP
.\"O One solution for this is to call, during the processing of event 47,
.\"O .BR epoll_ctl ( EPOLL_CTL_DEL )
.\"O to delete file descriptor 13 and
.\"O .BR close (2),
.\"O then mark its associated
.\"O data structure as removed and link it to a cleanup list.
.\"O If you find another
.\"O event for file descriptor 13 in your batch processing,
.\"O you will discover the file descriptor had been
.\"O previously removed and there will be no confusion.
¤³¤ÎÌäÂê¤ò²ò·è¤¹¤ë 1 ¤Ä¤ÎÊýË¡¤Ï¡¢¥¤¥Ù¥ó¥È 47 ¤Î½èÍý¤ò¤·¤Æ¤¤¤ë´Ö¤Ë¡¢
¥Õ¥¡¥¤¥ë¥Ç¥£¥¹¥¯¥ê¥×¥¿ 13 ¤òºï½ü¤·¤Æ
.BR close (2)
¤¹¤ë¤¿¤á¤Ë
.BR epoll_ctl ( EPOLL_CTL_DEL )
¤ò¸Æ¤Ó½Ð¤·¡¢´ØÏ¢ÉÕ¤±¤é¤ì¤¿ data ¹½Â¤ÂΤòºï½üºÑ¤ß¤È¥Þ¡¼¥¯¤·¤Æ¡¢
¥¯¥ê¡¼¥ó¥¢¥Ã¥×¥ê¥¹¥È¤Ë¥ê¥ó¥¯¤¹¤ë¤³¤È¤Ç¤¢¤ë¡£
¥Ð¥Ã¥Á½èÍý¤ÎÃæ¤Ç¥Õ¥¡¥¤¥ë¥Ç¥£¥¹¥¯¥ê¥×¥¿ 13 ¤Ë¤Ä¤¤¤Æ¤Î
¾¤Î¥¤¥Ù¥ó¥È¤ò¸«¤Ä¤±¤¿¾ì¹ç¡¢
¤½¤Î¥Õ¥¡¥¤¥ë¥Ç¥£¥¹¥¯¥ê¥×¥¿¤¬°ÊÁ°¤Ëºï½ü¤µ¤ì¤¿¤â¤Î¤Ç¤¢¤ë¤Èʬ¤«¤ë¤Î¤Ç¡¢
º®Íð¤Ïµ¯¤­¤Ê¤¤¡£
.\"O .SH VERSIONS
.SH ¥Ð¡¼¥¸¥ç¥ó
.\"O The
.\"O .B epoll
.\"O API was introduced in Linux kernel 2.5.44.
.B epoll
API ¤Ï Linux ¥«¡¼¥Í¥ë 2.5.44 ¤ËƳÆþ¤µ¤ì¤¿¡£
.\"O .\" Its interface should be finalized in Linux kernel 2.5.66.
.\" ¥¤¥ó¥¿¥Õ¥§¡¼¥¹¤Ï Linux ¥«¡¼¥Í¥ë 2.5.66 ¤Ç³ÎÄꤵ¤ì¤ë¤Ù¤­¤Ç¤¢¤ë¡£
.\"O Support was added to glibc in version 2.3.2.
glibc ¤Ç¤Î¥µ¥Ý¡¼¥È¤Ï¥Ð¡¼¥¸¥ç¥ó 2.3.2 ¤ÇÄɲ䵤줿¡£
.\"O .SH CONFORMING TO
.SH ½àµò
.\"O The
.\"O .B epoll
.\"O API is Linux-specific.
.\"O Some other systems provide similar
.\"O mechanisms, for example, FreeBSD has
.\"O .IR kqueue ,
.\"O and Solaris has
.\"O .IR /dev/poll .
.B epoll
API ¤Ï Linux ¸ÇÍ­¤Ç¤¢¤ë¡£
¾¤Î¥·¥¹¥Æ¥à¤Ç¤âƱÍͤε¡¹½¤¬Ä󶡤µ¤ì¤Æ¤¤¤ë¾ì¹ç¤¬¤¢¤ë¡£
Î㤨¤Ð¡¢FreeBSD ¤Î
.I kqueue
¤ä Solaris ¤Î
.I /dev/poll
¤Ê¤É¤Ç¤¢¤ë¡£
.\"O .SH "SEE ALSO"
.SH ´ØÏ¢¹àÌÜ
.BR epoll_create (2),
.BR epoll_create1 (2),
.BR epoll_ctl (2),
.BR epoll_wait (2)