Epoll

1. Epoll

• 1. Epoll
  • 1.1. 목적
  • 1.2. epoll이란
  • 1.3. epoll과 IOCP
    • 1.3.1. epoll_event
      • 1.3.1.1. union
    • 1.3.2. 레벨 트리거 vs 엣지 트리거
      • 1.3.2.1. 엣지 트리거
  • 1.4. 세마포어

1.1. 목적

2주간 Epoll로 에코 서버를 만들었다. 그 과정에서 알아낸 것들을 정리한다는게 목적. 쓰다보면 epoll과는 무관한 것들이 나올 수 있겠지만, 서버를 만들다보니 알게 된 것들을 정리하는게 이 글을 쓰는 목적이니 그냥 넘어가줬으면 좋겠다.

1.2. epoll이란

epoll은 linux에서 지원하는 입출력 이벤트 통지(?) 모델이다.

1.3. epoll과 IOCP

큰 차이가 없다. 사용하는 함수에서의 차이만이 있을 뿐. 입출력 이벤트 통지의 개념만 알고있다면, 사용하는데는 큰 문제가 없을 것같다.

1.3.1. epoll_event

epoll_event를 굳이 쓴 이유는 뭐냐면, 이게 가장 큰 걸림돌이 됬었었다. epoll_event.data에는 void*과 int(fd용), uint32, uint64가 멤버로 있다. 나는 그중 uint32에 유저의 식별번호를 담아서 이벤트가 발생했을 떄에, 유저매니저가 이 식별번호로 유저를 찾아내게 만들고 있었다. 등록할 떄에 에러가 발생하지 않았는데, 무슨 이유에서인지 이벤트가 무한정 발생했다. 이 버그의 원인은 event_epoll에 있었다. event_epoll.data는 union으로 되어있다.
union은 C에 나오는데, 이게 골때리는 놈이다. 그냥 이런 키워드가 있다는 것만 알고 한 번도 써본 적이 없었고 본 적도 없었는데, 여기서 이렇게 날 골탕먹일줄은 몰랐다.

1.3.1.1. union

union은 공동체라고 흔히들 비유한다. 적절한 말이라고 생각하는데...union은 멤버중 가장 큰 형으로 선언된 멤버로 메모리를 잡는다.

union A
{
    char a;
    int _a;
    long long _a;
}

라고 정의되어있다면, 이 union A는 long long인 8바이트만큼 메모리를 잡고, 모든 변수가 공유한다. 이걸 활용하는 이유랑 장점은 바로 다른 방법으로 user를 찾아버렸기에...다음에 생각나면 정리해보자.

1.3.2. 레벨 트리거 vs 엣지 트리거

epoll의 두 동작방식이다. epoll을 사용한다면 둘 중 하나를 선택해야한다. 디폴트는 레벨 트리거

레벨 트리거는 특정 상태가 유지되는 동안 감지
엣지 트리거는 특정 상태가 변화하는 시점에만 감지

예를들어서 디지털 신호 0011100011에서 1이 트리거라면 레벨 트리거는 1이 유지되는 시간동안 횟수에 상관없이 발생하고, 엣지 트리거는 0에서 1로 변하는 시점에서만 발생한다.

1.3.2.1. 엣지 트리거

장점

1. 다중 스레드에서 epoll_wait했을 때, 하나의 스레드만 통보를 받는다.
2. EPOLLOUT로 쓰기 가능 플래그를 일일히 add/del하지 않는다. (이거 좀 좋다.)

단점

1. 송수신으로 EAGAIN이 왔을 떄, 모든 데이터를 송수신했는지 확신할 수 없다.
2. 많은 데이터를 송/수신 했을 때에, 모든 데이터를 처리했는지 확인해야한다. 이것은 애플리케이션 측에서 책임을 져야한다. 각 디스크립터에대한 송/수신 데이터를 개인 데이터 영역에 일시저장해야한다 (...)

1.4. 세마포어

세마포어는 윈도우의 커널 오브젝트와 유사한걸로 이해하고 있다. 어떻게 작동하는지는 둘째치고, 커널 오브젝트의 대체로 사용할 수 있었다.