Level-triggered is the default mode for epoll. It is also how poll() and select() work. The rule is simple:

Think of it like a water sensor. As long as there is water in the tank, the sensor stays ON. It doesn’t matter when the water arrived — if water is still there, the sensor triggers.

Benefit: You can use blocking file descriptors and read partial data. The kernel keeps reminding you until you finish reading. This is safe and easier to program.

Edge-triggered mode works very differently. The rule here is:

Think of it like a doorbell. The bell rings when someone presses the button. If you ignore it and no one presses again, the bell won’t ring again on its own — even if the person is still standing at the door.

This means with edge-triggered mode, when you get a ready notification, you must read all available data immediately — keep reading until the system call returns EAGAIN or EWOULDBLOCK. That’s the signal that the buffer is empty.

This is why edge-triggered epoll requires nonblocking file descriptors. If you use a blocking fd and try to read past the available data, your process would block forever.

To switch a specific fd to edge-triggered mode, just add the EPOLLET flag when calling epoll_ctl(). You can mix LT and ET file descriptors in the same epoll instance.

#include <sys/epoll.h>

struct epoll_event ev;

/* Register fd in EDGE-TRIGGERED mode */
ev.data.fd = fd;
ev.events  = EPOLLIN | EPOLLET;   /* <-- EPOLLET makes it edge-triggered */

if (epoll_ctl(epfd, EPOLL_CTL_ADD, fd, &ev) == -1) {
    perror("epoll_ctl");
    exit(1);
}

/* For LEVEL-TRIGGERED (default), simply omit EPOLLET: */
ev.events = EPOLLIN;              /* level-triggered */

Let’s trace exactly what happens in both modes with a concrete scenario: 100 bytes arrive on a socket, but you only read 50 bytes on the first notification.

This is the silent bug in edge-triggered mode. If you partially read data and go back to epoll_wait(), your server will appear to work (epoll_wait returns) but the 50 remaining bytes are never processed — until the client sends more data, which triggers a new edge. This can cause subtle protocol bugs.

The behavior of edge-triggered epoll is described as “semantically similar to signal-driven I/O.” Both tell you about I/O events, not I/O state. But there is one important difference:

This makes ET epoll more reliable than signal-driven I/O for high-throughput scenarios, since coalescing prevents notification overflow.

The key difference in application code is the read loop. With LT you can read once per notification; with ET you must loop until EAGAIN.

#include <stdio.h>
#include <unistd.h>
#include <fcntl.h>
#include <errno.h>
#include <sys/epoll.h>

/* Make a file descriptor nonblocking — required for ET mode */
void set_nonblocking(int fd)
{
    int flags = fcntl(fd, F_GETFL, 0);
    fcntl(fd, F_SETFL, flags | O_NONBLOCK);
}

/* ===== LEVEL-TRIGGERED read handler ===== */
/* Safe to read just some data; epoll_wait() will notify again if more remains */
void lt_read_handler(int fd)
{
    char buf[512];
    ssize_t n = read(fd, buf, sizeof(buf));
    if (n > 0) {
        /* Process buf[0..n-1] */
        printf("[LT] Read %zd bytes\n", n);
        /* If there's more data, epoll_wait() will fire again automatically */
    } else if (n == 0) {
        printf("[LT] Connection closed by peer\n");
    } else {
        perror("[LT] read error");
    }
}

/* ===== EDGE-TRIGGERED read handler ===== */
/* MUST drain all data until EAGAIN, otherwise data is stuck silently */
void et_read_handler(int fd)
{
    char buf[512];
    ssize_t n;

    /* Keep reading until the kernel says "buffer empty" (EAGAIN/EWOULDBLOCK) */
    while (1) {
        n = read(fd, buf, sizeof(buf));
        if (n > 0) {
            /* Process buf[0..n-1] */
            printf("[ET] Read %zd bytes\n", n);
            /* Continue loop — there may be more data */
        } else if (n == 0) {
            printf("[ET] Connection closed by peer\n");
            break;
        } else {
            if (errno == EAGAIN || errno == EWOULDBLOCK) {
                /* Buffer is fully drained — safe to go back to epoll_wait() */
                printf("[ET] Buffer drained (EAGAIN), returning to epoll_wait\n");
                break;
            } else {
                perror("[ET] read error");
                break;
            }
        }
    }
}

int main(void)
{
    int epfd = epoll_create1(0);
    struct epoll_event ev, events[10];

    int fd = STDIN_FILENO;  /* Use stdin for this demo */

    /* For ET: fd MUST be nonblocking */
    set_nonblocking(fd);

    /* Register with EPOLLET (edge-triggered) */
    ev.data.fd = fd;
    ev.events  = EPOLLIN | EPOLLET;
    epoll_ctl(epfd, EPOLL_CTL_ADD, fd, &ev);

    printf("Waiting for input (edge-triggered mode)...\n");

    int nfds = epoll_wait(epfd, events, 10, -1);
    for (int i = 0; i < nfds; i++) {
        if (events[i].events & EPOLLIN) {
            et_read_handler(events[i].data.fd);
        }
    }

    close(epfd);
    return 0;
}

Answer: In level-triggered (LT) mode, epoll_wait() returns a file descriptor as ready whenever data is available in its buffer — it keeps notifying you every call until you drain the data. In edge-triggered (ET) mode, epoll_wait() notifies you only when a new I/O event occurs (like new data arriving). If you don’t drain all the data during that notification, no further notification is sent until more data arrives. ET mode requires nonblocking I/O and draining the buffer until EAGAIN.

Answer: In ET mode, you must read until the buffer is empty (EAGAIN). If the file descriptor is blocking and you try to read more data than what’s in the buffer, the read() call will block indefinitely — hanging your server. With nonblocking mode, read() immediately returns EAGAIN when the buffer is empty, letting you know it’s safe to stop and go back to epoll_wait().

Answer: The EPOLLET flag enables edge-triggered mode. You set it in the ev.events field when calling epoll_ctl(): ev.events = EPOLLIN | EPOLLET;. It is per file descriptor — other fds in the same epoll instance are not affected and remain level-triggered by default.

Answer: Both notify about I/O events (not I/O state), meaning you are told when something changes, not whether data is present. The key difference is notification coalescing: if multiple I/O events happen before your application responds, epoll gives a single notification for all of them (coalesced). Signal-driven I/O can generate multiple signals, one per event, and under heavy load the signal queue can overflow causing notifications to be lost. ET epoll is therefore more reliable.

Answer: Yes. The EPOLLET flag is set per file descriptor at registration time via epoll_ctl(). You can have some file descriptors registered with EPOLLET (ET mode) and others without it (LT mode, the default) in the same epoll instance. A common pattern is to keep the listening server socket in LT mode and register accepted client sockets in ET mode.

Answer: The unread data stays in the kernel receive buffer, but epoll_wait() will NOT notify you again unless new data arrives. This leads to a subtle bug: if the client sends data and then waits for a response, your server will never process the remaining data and will never send the response. Both sides will block indefinitely. This is sometimes called a “data starvation” bug and is one of the most common mistakes when first using EPOLLET.