[Reprint] Understanding the event triggering mechanism of Epoll

Original: http://weibo.com/p/1001603862394207076573?sudaref=weibo.com

There are two modes of Epoll I/O event triggering: ET (Edge triggered) and LT (level triggered).

This trigger pattern is actually a property of events, which is tied to and mixed with attributes such as Pollin, Pollout, and events are sometimes attached to the FD (file descriptor), so it can be said that this trigger mode is the attribute of the FD that events is attached to. The reason for the distinction between events and FD is that kernel internal implementations are also so differentiated: events are represented by Eppoll_entry, and FD is represented by Epitem.

Let's take a quick look at both of these patterns.

Lt mode is for an escalation event, if not finished, then the next time the event is still, you can continue processing. In the same scenario, the ET mode processing is: The next time the event is not, that is, to notify only once, do not give the opportunity of the second processing. The default mode of Epoll is LT, after all, Select/poll only supports the LT mode.

Look at the ET mode first.

Basic description of ET mode:

An application this employs the Epollet flag should use nonblocking file descriptors to avoid have a blocking read or WR  Ite starve a task is handling multiple file descriptors. The suggested-Epoll as an edge-triggered (Epollet) interface are as follows:

1) with nonblocking file descriptors; and

2) by waiting a event only after read (2) or write (2) return Eagain.

By contrast while used as a level-triggered interface (the default, when Epollet was not specified), Epoll is Simpl Y a Faster poll (2), and can be used wherever the latter is used since it shares the same semantics.

It can be seen that the ET mode uses non-clogging FD and uses a poor-polar approach to handle the event (until a satisfactory eagain return value is obtained). Let's take a closer look at the process of handling events:

Q:do I need to continuously read/write a file descriptor until Eagain when using the Epollet flag (edge-triggered behavior)?

A:receiving an event from epoll_wait (2) should suggest to you, such file descriptor is ready for the requested I/O op Eration.  You must consider it ready until the next (nonblocking) Read/write yields eagain. When and what you'll use the file descriptor are entirely up to you.

For packet/token-oriented files (e.g, datagram sockets, terminal in canonical mode), the only-to-detect the end of The read/write I/O space is to continue to read/write until Eagain.

For stream-oriented files (e.g, pipe, FIFO, stream sockets), the condition that the read/write I/O space is exhausted  Can also is detected by checking the amount of data read From/written to the target file descriptor. For example, if-call-read (2) by asking to read a certain amount of data and read (2) returns a lower number of bytes,  You can be sure of have exhausted the read I/O space for the file descriptor.  The same is true when writing using Write (2). (Avoid This latter technique if you can‐not guarantee so the monitored file descriptor always refers to a stream-oriente d file.)

In other words, there are two ways to end the judgment: look at the Eagain return value, compare the expected count and the true count.

One thing to note about the ET pattern is that in the ready queue of eventpoll (which identifies a epoll instance), the FD attached to events is placed, not events itself. This can lead to a piggyback phenomenon: Once a Pollin event is triggered, no longer occurs, although the user is not finished processing. But a new pollout incident came, at which time the old Pollin incident came out again. (for example, the person is FD, the new account of the old account is different events, it is similar to: there is no matter, do not meet on the line.) Afraid of a new account, with a new account, you have to meet and new accounts together ... )

We think that theet mode is still very reasonable , with the network card NAPI read packet way very much like, all with poll (efficient: For Epoll, after all, save a lot of extra epoll system calls the number of times) features ...

Look at the LT mode again.

Why first look at ET and see LT? Because from the implementation of the code, we think that the epoll should be supported by ET after the addition of the support Lt.

The support for LT is simple and requires only a few more lines of code on the basis of the existing ET implementation:

Once the escalation event is processed, the event is re-placed back into the ready queue of eventpoll (which identifies an Epoll instance), which means that the event is given directly (in fact, the Epitem, the file descriptor attached to the event) for the second processing Opportunity (ET mode is not the opportunity), although this opportunity may not be required: Because the user may be the first to deal with the poor pole of the event. It can be seen that the process of the LT mode is somewhat inefficient (especially in the case of large FD numbers).

In conclusion, Epoll implements two modes of notification mode for I/O events: LT and ET, and in terms of efficiency, et should be more advantageous.

[Reprint] Understanding the event triggering mechanism of Epoll