select y poll: readiness que no escala

select llegó con 4.2BSD en 1983 y poll con System V poco después; durante décadas fueron la única forma portable de que un hilo esperase sobre varios descriptores. Ambos entregan lo prometido —te dicen cuáles de tus fds están listos— y ambos comparten el defecto que los condenó a escala grande: cada llamada cuesta O(n) sobre el total de descriptores vigilados, tengas uno activo o diez mil dormidos. Entender por qué ese coste es estructural, y no un detalle de implementación, es entender exactamente qué problema vino a resolver epoll.

select: el conjunto de descriptores como mapa de bits

select representa el interés con un fd_set, un mapa de bits de tamaño fijo FD_SETSIZE, que en Linux vale 1024. Manipulas los bits con FD_ZERO, FD_SET, FD_CLR y consultas el resultado con FD_ISSET. El primer argumento, nfds, es el descriptor más alto más uno: le dice al kernel cuántos bits recorrer.

/* select: reconstruir el conjunto en CADA iteracion */
fd_set rset;
struct timeval tv;
int maxfd = calcular_max(conns);

for (;;) {
	FD_ZERO(&rset);
	for (int i = 0; i < nconns; i++)
		FD_SET(conns[i].fd, &rset);   /* el kernel destruye el conjunto: hay que rehacerlo */

	tv.tv_sec = 1; tv.tv_usec = 0;    /* Linux tambien reescribe tv: hay que resetearlo */

	int listos = select(maxfd + 1, &rset, NULL, NULL, &tv);
	if (listos < 0) { if (errno == EINTR) continue; break; }

	for (int i = 0; i < nconns; i++)
		if (FD_ISSET(conns[i].fd, &rset))   /* recorrer TODOS para hallar los pocos listos */
			atender(&conns[i]);
}

select arrastra tres trampas. Modifica los conjuntos en el sitio —a la vuelta contienen solo los listos—, así que hay que reconstruirlos en cada iteración; en Linux también reescribe el timeout con el tiempo restante, obligando a reponerlo; y sobre todo, un descriptor cuyo número iguale o supere FD_SETSIZE desborda el mapa de bits y corrompe la pila, un comportamiento indefinido que ningún casteo arregla. Ese tope de 1024 es una barrera dura contra el propio problema C10k.

poll: el array de pollfd sin tope fijo

poll sustituye el mapa de bits por un array de estructuras, una por descriptor, y con ello elimina el límite de 1024. Cada struct pollfd separa lo que pides de lo que recibes: tú rellenas events, el kernel rellena revents.

struct pollfd {
	int   fd;        /* descriptor a vigilar          */
	short events;    /* lo que pido: POLLIN, POLLOUT   */
	short revents;   /* lo que el kernel devuelve      */
};

/* poll: sin limite de 1024, pero aun pasas y recorres el array entero */
struct pollfd fds[MAX];
for (int i = 0; i < nconns; i++) {
	fds[i].fd     = conns[i].fd;
	fds[i].events = POLLIN;
	fds[i].revents = 0;
}

int listos = poll(fds, nconns, 1000);   /* timeout en milisegundos, no lo reescribe */
if (listos > 0)
	for (int i = 0; i < nconns; i++)
		if (fds[i].revents & POLLIN)       /* de nuevo, recorrer los N para hallar los listos */
			atender(&conns[i]);

Como events y revents son campos distintos, no hace falta reconstruir el interés en cada vuelta: basta poner revents a cero. Es una mejora ergonómica real sobre select, y poll distingue además condiciones que select mezcla, como POLLHUP para el cierre o POLLERR para el error. Pero el coste de fondo no cambia: sigues entregando el array completo en cada llamada y sigues recorriéndolo entero a la vuelta.

Tres condiciones de revents son de salida pura: no puedes pedirlas en events, pero el kernel las entrega y hay que atenderlas. POLLHUP señala que el par cerró su extremo, POLLERR un error del descriptor y POLLNVAL que el fd no es válido, casi siempre un fallo de tu propia contabilidad. Ignorarlas es un error clásico: un socket con POLLHUP que solo compruebas contra POLLIN se queda vivo para siempre en tu conjunto, girando sin que nadie lo cierre.

Por qué O(n): el kernel padece amnesia

El defecto es estructural, no de código. Cada llamada a select o poll paga varios recorridos de longitud n sobre el conjunto vigilado. El kernel copia desde espacio de usuario el conjunto entero; recorre los n descriptores invocando el f_op->poll de cada uno para inscribirse en su cola de espera y leer su disponibilidad; si nada está listo, duerme; al despertar, vuelve a recorrer los n para ver cuál se activó; copia el resultado de vuelta; y aún te toca a ti recorrer los n para encontrar los pocos con revents.

/* fs/select.c, esquema de do_poll: en cada llamada se recorre TODO el conjunto */
for (;;) {
	for (i = 0; i < n; i++)
		mask = vfs_poll(fds[i].file, &table);  /* f_op->poll: inscribe y consulta, O(n) */
	if (hay_listos || agotado_el_timeout)
		break;
	schedule_timeout(...);                     /* duerme; al despertar recorre otra vez */
}
poll_freewait(&table);   /* al volver, DESINSCRIBE todo: nada persiste entre llamadas */

La clave está en la última línea: al regresar, poll_freewait deshace todas las inscripciones en las colas de espera. El kernel no guarda ninguna memoria de tu conjunto de interés; en la próxima llamada empiezas de cero. Con diez mil descriptores y uno solo activo, realizas del orden de diez mil unidades de trabajo por cada evento útil. El coste escala con lo que vigilas, no con lo que ocurre, y esa es la definición precisa del muro contra el que chocan select y poll.

sequenceDiagram
participant U as Userspace
participant K as Kernel
U->>K: poll con N descriptores
K->>K: recorre los N e inscribe en cada cola
K-->>U: duerme hasta que alguno este listo
K->>K: despierta y recorre los N otra vez
K-->>U: devuelve el array con revents
U->>U: recorre los N buscando los listos
Note over U,K: al volver el kernel desinscribe todo