여러 개의 스레드가 같은 epoll fd를 어떻게 조작합니까

자신이 이전에 인터페이스 서버를 만들었을 때 이런 장면에서 나의 디자인은 여러 개의 라인이 같은 epoll fd를 조작하는 것이다.그때, 나의 이유는 epoll의 계열 함수가 라인이 안전하다는 것이다.
물론 어떤 사람들은 왜 여러 개의 라인이 같은 epoll fd를 조작하는지 이해하지 못한다. 여기에 인터페이스 서버의 장면을 살짝 설명한다.epoll fd는 라인 1 유지보수가 있습니다. 서버 포트를 감청하는 socket의 acceptor (즉 새로운 socket fd) 도 이 epoll fd에 있습니다.클라이언트 링크 요청을 받았을 때, 루트 2는 연결 탱크connectorpool에서connector를 선택합니다.connector의 역할은 요청을 전달하는 것입니다. 이 때connector는acceptor를 캐시합니다.만약connector가 응답을 받은 후,connector는acceptor를 통해 클라이언트에게 데이터를 되돌려줍니다. 루트 2는 이때acceptor를add에 epoll fd에 넣어야 합니다.
이전에 나는 epoll fd가 다중 노드가 안전하다고 생각했는데, 나는 직접 epoll_를 통과했다ctl(epoll fd,acceptor,add)는 acceptor를 epoll fd에 넣습니다.
이제 다시 한 번 돌이켜 보면, 자신이 당연하게 이렇게 조작했으니, 아무런 근거도 없다.맹자가 이르되 행할 수 없는 것이 있으면 자기에게 반구하라.기왕 자신이 곤혹을 풀 수 없다면, 위대한 맨에게 도움을 청해야 한다."man epoll_wait"를 통해 다음과 같은 말을 얻을 수 있습니다.

NOTES
       While one thread is blocked in a call to epoll_pwait(), it is possible for another thread to add a file descriptor to the waited-upon epoll instance.  If the new file descriptor becomes ready, it will cause the epoll_wait() call to unblock.

       For a discussion of what may happen if a file descriptor in an epoll instance being monitored by epoll_wait() is closed in another thread, see select(2).

만약에 한 라인이 epoll_에 막히면pwait에서 이 epoll fd에 socket fd를 추가하는 다른 라인이 있을 수 있습니다. 만약 이 새로운 socket fd가 추가된 후ready 상태에 있다면, epoll_wait는 더 이상 막힌 상태에 있지 않을 것이다.만약에 epoll fd가 감시하는 socket fd가 다른 라인close에 의해 떨어진다면 시스템이 어떤 상태인지select(2)를 참고하십시오."man 2 select"를 통해 다음과 같은 구절을 얻을 수 있습니다.

   Multithreaded applications
       If a file descriptor being monitored by select() is closed in another thread, the result is unspecified.  On some UNIX systems, select() unblocks and returns, with an indication that the file descriptor is ready (a subsequent I/O operation will likely fail with an error, unless another the file descriptor reopened between the time select() returned  and the I/O operations was performed).  On Linux (and some other systems), closing the file descriptor in another thread has no effect on select().  In summary, any application that relies on a particular behavior in this scenario must be considered buggy.

번역 후, 그 의미는 만약에 한 라인에서select가 관리하는 socket이 다른 라인에 의해 닫히면 무슨 일이 일어날지 하늘만이 알 수 있다는 것이다.일부 유닉스 시스템에서 select는 막힌 상태를 끝내고 되돌아옵니다. 이것은 이 socket이ready 상태라는 것을 표시합니다. (뒤에 이 socket에 대한 작업이 실패할 수 있습니다. os도 이 socket을 되돌려주고 프로세스가 이 socket을 읽는 동안 os가 같은 socket fd를 분배하지 않는 한 오류 알림을 보냅니다.)linux (다른 같은 종류의 시스템) 에서 이런 행위는 select (즉 막힌 상태가 비막힌 상태로 변하는 것) 에 영향을 주지 않는다.한 마디로 하면 프로그램에서 이런 행위는 버그로 여겨져야 한다.
상기 두 단락의 맨전신시를 통해 한 라인이 epoll 또는select에서 한 socket을 감시할 때 다른 라인이 이 socket에 대해close를 하는 상황을 제외하고 나는 여러 라인이 같은 epoll fd를 조작하는 행위가 안전하다고 생각할 수 있다. 즉, 내 위의 조작은 문제가 없다.
이상은 개인의 우견입니다. 여러분의 비판과 시정을 간청합니다.
또 추쿠'www.tuicool.com'같은 쓰레기 표절 사이트가 본인의 허락 없이 본인의 블로그를 옮기는 행위를 엄격히 규탄한다.