출처 : http://www.linux.or.jp/JM/html/LDP_man-pages/man4/epoll.4.html
번역 :
EPOLL
Section: Linux Programmer's Manual (4)
Updated:
Index JM Home Page roff page
이름
서식
#include <sys/epoll.h>
설명
epoll은 poll의 일종이며 edge trigger 인터페이스
또는 level trigger 인터페이스로서 사용하는 것이 가능하고 감시하는 파일 디스크립터의 수가
많은 경우에도 사용할 수 있다. epoll
세트를 설정하거나 제어하거나 하기 위해서 다음의 3개의 시스템 콜이 제공되고 있다: epoll_create, epoll_ctl, epoll_wait
epoll 세트는 epoll_create 으로 작성되는 파일 디스크립터에 접속된다. 그리고 특정의 파일 디스크립터에
대한 관심 (역주: 어떤 이벤트를 감시할까 등)을 epoll_ctl 로 등록한다. 마지막에 epoll_wait 로
실제의 이벤트 대기를 개시한다.
주의
epoll 이벤트 배송 (distribution) 인터페이스는 edge trigger (ET) 라고
해도 level trigger (LT) 라고 해도 동작시킬 수가 있다.
ET 이벤트 배송 기구와 LT 이벤트 배송 기구의 차이는 다음과 같이 설명할 수 있다. 이러한
시나리오가 일어났다고 하자:
1
파이프의 읽기 측을 나타내는 파일 디스크립터
(RFD) 가 epoll 디바이스의
내부에 추가된다.
2
파이프에 쓰기를 하는 프로그램이 2Kb 의
데이터를 파이프의 쓰기측에 기입한다.
3
epoll_wait 를 호출하면 읽기 가능(ready)인 파일 디스크립터로써 RFD가 돌아간다.
4
파이프로부터 읽어내는 프로그램이 1Kb 의
데이터를 RFD로부터 읽어낸다.
5
epoll_wait의 호출을 한다.
RFD 파일 디스크립터가
EPOLLET 플래그를 사용해 epoll 추가되고 있으면 이용 가능한 데이터가 파일 입력 버퍼에
아직 존재해 리모트의 접속처(peer)가 이미 보내진 데이터에 근거해 응답을 기대하고 있기 때문에 스텝
5의 epoll_wait 의 호출로 행할 가능성이 있다. 이것은 edge trigger 이벤트 배송에서는 모니터 하고 있는 파일로 이벤트가 떠났을 때에만 이벤트가 배송되기 때문에
있다. 상기의 예에서는 2로 행해진 쓰기에 의해
RFD 에 관한 이벤트가 생성되어 3로 이벤트가 소비 (consume) 된다.
4 로 행해지는
읽기 조작에서는 전부의 버퍼 데이터를 소비하지 않기 때문에 스텝 5 에서 행해지는 epoll_wait 의 호출이 무기한으로 잠글지도
모른다. EPOLLET
플래그 (edge trigger)와 함께 사용하는 경우 epoll 인터페이스는 블록 하지 않는 파일 디스크립터를 사용해야 하는 것이다. 이것은
블록 되는 읽기나 기입에 의해 , 복수의 파일 디스크립터를 취급하는 태스크를 굶주림(starve) 시키지 않게 하기 위한 것이다. epoll 를 edge trigger (EPOLLET) 인터페이스로서 사용하기 위해서 제안되는 방법은 이하와 같고
흔히 있는 함정을 피하는 방법도 계속해 말한다.
i
블록 하지 않는 파일 디스크립터와 함께 사용한다.
ii
read(2) 또는 write(2) 이 EAGAIN 를 돌려준 다음에만 이벤트를 기다린다.
반대로 level trigger 인터페이스로서
사용하는 경우는 epoll 은 정말로 보다 고속의
poll이며 사용법이 같아서 poll이 사용되고 있는 곳은 어디에서라도 사용할 수가 있다.
edge trigger를 사용했을 경우에서도 복수의 데이터를 수신하면 복수의 epoll 이벤트가 생성되므로 호출 측에는 EPOLLONESHOT 플래그를 지정하는 옵션이 있다. 이 플래그는 epoll에 대해서 epoll_wait 에 의한 이벤트를 수신한 다음에
관련하는 파일 디스크립터를 무효로 시킨다. EPOLLONESHOT 플래그가 지정되었을 경우
epoll_ctl 에 EPOLL_CTL_MOD 를 지정해 파일 디스크립터를 재차 사용할 수 있도록 하는 것은 호출 측의 책임이다.
제안하는 사용법의 예
level trigger 인터페이스로서 사용할 때 epoll 의 사용법은 poll과 같다. 그러나 edge trigger로서 사용하는 경우는 어플리케이션의 이벤트 루프로
stall(stall) 하지 않게 사용법을 보다 명확하게
해 둘 필요가 있다. 이 예에서는 리스너는 블록 하지 않는 소켓이며 listen이 불리고 있다. 함수 do_use_fd()는 read 또는 write에 의해 EAGAIN 가 돌려주어질 때까지는
새로울 준비 끝난 파일 디스크립터를 사용한다. 이벤트 구동 스테이트 머신 어플리케이션은 EAGAIN (을)를 수신한 후 경향 상태를 기록해 두어야 하는 것이다. 이것에 의해 다음의 do_use_fd() 호출 때에 이전에 정지
했는데로부터 read 또는 write(2) 을 계속할 수가 있다.
struct epoll_event ev, *events;
for(;;) {
nfds = epoll_wait(kdpfd,
events, maxevents, -1);
for(n = 0; n < nfds; ++n)
{
if(events[n].data.fd == listener) {
client = accept(listener, (struct sockaddr *) &local,
&addrlen);
if(client < 0){
perror("accept");
continue;
}
setnonblocking(client);
ev.events = EPOLLIN | EPOLLET;
ev.data.fd = client;
if (epoll_ctl(kdpfd, EPOLL_CTL_ADD, client, &ev) < 0) {
fprintf(stderr,
"epoll set insertion error: fd=%d,
client);
return -1;
}
}
else
do_use_fd(events[n].data.fd);
}
}
edge trigger 인터페이스로서 사용하는 경우 성능상의 이유에 의해 한 번 (EPOLLIN|EPOLLOUT)
을 지정하고 나서 (EPOLL_CTL_ADD) 로 파일 디스크립터를 epoll 인터페이스에 추가할 수가 있다. 이것에 의해 epoll_ctl에 EPOLL_CTL_MOD를 지정해 호출하는 것으로 EPOLLIN 와 EPOLLOUT 의
연속적인 바뀜을 피할 수 있다.
질문과 해답 (linux-kernel 보다)
Q1
같은 파일 디스크립터를 1개의 epoll_set 에 2회 추가하면 어떻게 될까?
A1
아마 EEXIST를 받을 것이다. 그러나 2개의 thread가
같은 파일 디스크립터를 2 회 추가하는 것은 가능하다. 이것은
무해인 상태이다.
Q2
2개 epoll세트가 같은 파일 디스크립터를 기다리는
것은 가능한가? 만약 가능하면 이벤트는 양쪽 모두 epoll 세트의 파일 디스크립터에 보고될까?
A2
가능하지만 추천 되지 않는다. 그리고
이벤트는 양쪽 모두에 보고된다.
Q3
epoll 파일 디스크립터
자신은 poll/epoll/select 이 가능한가?
A3
가능하다.
Q4
epoll 파일 디스크립터를
자신의 파일 디스크립터 세트에 넣으면 어떻게 될까?
A4
실패할 것이다. 다만 epoll 파일 디스크립터를 다른 epoll 파일 디스크립터 세트의 내부에 추가하는 것은 가능하다.
Q5
epoll 파일 디스크립터를 unix 소켓으로 다른 프로세스에 보내는 것은 가능한가?
A5
불가능하다.
Q6
파일 디스크립터를 클로우즈 그 파일 디스크립터는 모든 epoll 세트로부터 자동적으로 삭제될까?
A6
삭제된다.
Q7
2 개 이상의 이벤트가 epoll_wait 콜의 사이에 왔을 경우 그것들은
정리해 보고되는지 그렇지 않으면 따로 따로 보고될까?
A7
정리해 보고될 것이다.
Q8
파일 디스크립터에 대한 조작은 이미 모아지고 있지만 아직 보고되어 있지 않은
이벤트에 영향을 줄까?
A8
기존의 파일 디스크립터에 대해서 2개의
조작을 실시할 수가 있다. 이 경우 삭제에는 의미가 없다. 변경하면
사용 가능한 I/O 가 다시 읽힌다.
Q9
EPOLLET 플래그(edge trigger 동작)을 사용하고 있는 경우 EAGAIN 를 받을 때까지 계속해 파일 디스크립터를 읽고 쓰기할 필요가 있을까.
A9
그럴 필요는 없다. epoll_wait로부터 이벤트를 받는 것은 「그 파일 디스크립터가 요구된 I/O 조작에 대해서 준비가 끝난 상태이다」 라고 하는 것을 유저에게 나타내는 것이다. 「다음의 IN 을 받을 때까지는 파일 디스크립터는 준비가 끝난 상태이다」
와 단순하게 생각해야 하는 것이다. 그러한 파일 디스크립터를 언제 어떻게 사용할까는 완전히 유저에게
맡고 있다. 그리고 읽어들여 용 / 기입용 I/O 공간이 쓰여진 상태는 , 대상이 되는 파일 디스크립터로부터
읽어들인 데이터량 또는 기입한 데이터량을 체크하는 것으로 검지할 수 있다. 예를 들면 어느 특정의 양의
데이터를 읽어들이기 때문에 read를 불렀을 때에 read가 돌려준 아르바이트수가 그것보다 적었던 경우 그 파일 디스크립터의 읽기용 I/O 공간이 쓰여진 것을 안다. write 함수를 사용해 쓰시흫 할 때도 같은 것을 말할 수 있다.
흔히 있는 함정과 회피 방법
o 기아 (starvation) (edge trigger)
큰 I/O 공간이 있는 경우 그 I/O 공간의 데이터를 모두
처리(drain) 하려고 하면 다른 파일이 처리되지 않고 굶고를 발생시키는 일이 있다. 이것은 epoll 에
고유의 것은 아니다.
이 문제의 해결법은 준비가 끝난 상태의 리스트를 관리하며 관련하는
data 구조체 중에서 파일 디스크립터가 이용 가능하다 라고 마크 하는 것이다. 거기에
따라 이용 가능한 모든 파일 중에서 어느 파일을 처리할 필요가 있을까를 기억할 수가 있어 게다가 차례로 처리
(round robin) 할 수가 있다. 이미 이용 가능한 파일 디스크립터에 대해서 그것
이후에 받는 이벤트를 무시할 수도 있다.
o 이벤트 캐쉬를 사용하고 있는 경우
이벤트 캐쉬를 사용하고 있는 경우 또는 epoll_wait 로부터
반환된 모든 파일 디스크립터를 격납하고 있는 경우 클로우즈 된 것을 동적으로 마크 하는(즉 전의 이벤트의
처리에 의해 마크 되는) 방법을 제공해야 한다. epoll_wait로부터 100 개의 이벤트를 받아 이벤트 #47 인 조건으로 이벤트 13이 닫혀지면) 가정한다. 이벤트 13의
구조체를 삭제해 파일 디스크립터를 close()하면 이벤트 캐쉬는 그 파일 디스크립터를 기다리는 이벤트가
존재한다고 하여 혼란이 일어난다.
이 문제를 해결하는 1개의 방법은 이벤트 47의 처리를 하고 있는 동안에 파일 디스크립터 13을 삭제해 close() 하기 위해서 epoll_ctl(EPOLL_CTL_DEL)를 호출해 관련지을 수 있었던 data 구조체를
삭제가 끝난 상태와 마크 해 클린 업 리스트에 링크하는 것이다. 배치처리 중에서 파일 디스크립터 13에 대한 다른 이벤트를 찾아냈을
경우 그 파일 디스크립터가 이전에 삭제된 것이다고 알므로 혼란은 일어나지 않는다.
준거
epoll는 Linux 커넬 2.5.44 에 도입된 새로운 API 이다. 인터페이스는 Linux 커넬 2.5.66 로 확정 되는 것이 당연하다.