How multiple threads operate the same epoll FD

I used to do an interface server, this scenario under my design is that multiple threads operate the same epoll FD. At that time, my reason was that Epoll's series of functions were thread-safe.

Of course some people don't understand why there are multiple threads operating in the same epoll FD scenario, where the interface server scenario is slightly out. Epoll FD thread 1 maintenance, listen to the socket of the server port of the accept out acceptor (that is, the new socket FD) is also placed in this epoll FD. When a client link request is received, thread 2 picks it up from the connection pool connector pool and a connector,connector is the role of forwarding the request, at which point Connector will cache the acceptor. If connector receives a reply, connector will return some data to the client through acceptor, thread 2 needs to put acceptor in the Add Epoll fd at this point.

Before I thought Epoll FD is multithreaded security, I directly through Epoll_ctl (Epoll fd,acceptor,add) put acceptor into Epoll FD.

Now look back and see, I take it for granted that this operation, there is no basis. Mencius said, "The line is not, amending." Now that you can't solve the puzzle, ask for the great man. After "Man epoll_wait", get this sentence:

NOTES     While one thread was blocked in a call to Epoll_pwait (), it was possible for another thread to add a file descript Or to the Waited-upon Epoll instance.  If the new file descriptor becomes ready, it'll cause the epoll_wait () to unblock.     For a discussion of any happen if a file descriptor in an epoll instance being monitored by epoll_wait () are closed in Another thread, see Select (2).

        translation is: If a line is impersonating blocked on the epoll_pwait, At this point there may be another thread to add a socket FD to this epoll fd, if this new socket FD is added to the ready state, then epoll_wait will no longer be in a blocking state. If a socket fd monitored by Epoll FD is closed by another thread, please refer to select (2) for the status of the system. After "Man 2 Select", get the following paragraph:   

   Multithreaded Applications       If a file descriptor being monitored by select () are closed in another thread, the result is Unspecified.  On some UNIX systems, select () unblocks and returns, with a indication, the file descriptor are ready (a subsequent i/ O operation would 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 have no effect on select ().  In summary, any application it relies on a particular behavior in this scenario must is considered buggy.

After translation, the meaning is: if a thread in a select managed socket is close off by another thread, what will happen is only heaven knows. In some UNIX systems, select will end the blocking state and return it, which will identify the socket in the ready state (the operation behind the socket will fail and the OS will give an error, The OS assigns the same socket FD again, unless the select returns and the process has read and write the socket for the time period. On Linux (and other homogeneous systems), this behavior does not affect select (that is, the blocking state becomes nonblocking). In short, if this behavior in a program should be considered a bug (there should be no such action).

Through the divine display of the two above-mentioned man gods, in addition to one thread monitoring a socket in Epoll or select the other thread is close to this socket, I can assume that the behavior of multiple threads to operate the same Epoll FD is safe, That is, I have no problem with the above operation.

The above is a personal humble opinion, I implore everyone to criticize correct.

another stern condemnation like "Push Cool" www.tuicool.com "This rubbish plagiarism site reproduced without my permission my blog 's behavior.

How multiple threads operate the same epoll FD