El problema C10k: un hilo para miles de conexiones

Un servidor web en 2026 no atiende a diez clientes: mantiene abiertas cientos de miles de conexiones simultáneas, la mayoría inactivas casi todo el tiempo, esperando el siguiente byte. El modelo ingenuo —un hilo por conexión, cada uno dormido en su read— se derrumba mucho antes de llegar ahí: el planificador se ahoga, las pilas devoran gigabytes y la CPU se va en cambios de contexto. El problema C10k, bautizado por Dan Kegel a finales de los noventa, planteó la pregunta que define toda la E/S de red moderna: ¿cómo hace un solo hilo para vigilar miles de descriptores a la vez y despertar solo cuando alguno tiene trabajo?

Un hilo por conexión: el modelo que no escala

El diseño más natural asigna un hilo a cada cliente y deja que ese hilo se bloquee en su propio read. Es correcto y fácil de razonar, y por eso todo el mundo lo escribe primero.

/* modelo clasico: un hilo bloqueado por cada conexion */
for (;;) {
	int cfd = accept(lfd, NULL, NULL);   /* bloquea hasta que llega un cliente */
	if (cfd < 0)
		continue;
	pthread_create(&t, NULL, atender, arg_con(cfd));  /* un hilo mas */
}

static void *atender(void *arg)
{
	int cfd = fd_de(arg);
	char buf[4096];

	for (;;) {
		ssize_t n = read(cfd, buf, sizeof(buf));  /* el hilo existe solo para dormir aqui */
		if (n <= 0)
			break;
		procesar(buf, n);
	}
	close(cfd);
	return NULL;
}

El coste no es la CPU mientras los hilos duermen, sino lo que cada hilo reserva por el mero hecho de existir. En x86-64 cada uno arrastra una pila de kernel de 16 KiB clavada en memoria física, un task_struct, una entrada en las estructuras del planificador y una pila de usuario de varios megabytes reservada en el espacio de direcciones. Cien mil hilos son gigabytes de pilas y un planificador cuyas colas ya no caben en caché. Y cuando muchas conexiones se activan a la vez, el sistema paga una tormenta de despertares y cambios de contexto. El hilo, en este modelo, no es más que un cursor caro aparcado sobre un único descriptor bloqueante.

E/S bloqueante contra E/S por readiness

Por defecto un descriptor es bloqueante: read duerme al hilo hasta que hay datos. La bandera O_NONBLOCK invierte ese contrato: read y accept regresan al instante con -1 y errno igual a EAGAIN si no hay nada que entregar.

/* volver el descriptor no bloqueante: read/accept devuelven EAGAIN en vez de dormir */
int flags = fcntl(cfd, F_GETFL, 0);
fcntl(cfd, F_SETFL, flags | O_NONBLOCK);

Pero el modo no bloqueante por sí solo tienta con el peor patrón posible, el sondeo activo:

/* ANTIPATRON: sondeo activo, quema un nucleo entero para nada */
for (;;) {
	ssize_t n = read(cfd, buf, sizeof(buf));
	if (n < 0 && errno == EAGAIN)
		continue;   /* gira sin dormir jamas: 100% de un nucleo */
	/* ... */
}

O_NONBLOCK solo responde a “¿está listo este fd ahora mismo?”. Tenemos miles, y girar sobre todos ellos consume el núcleo entero sin realizar trabajo útil. Lo que falta es una llamada al sistema que reciba muchos descriptores y duerma al hilo hasta que al menos uno esté listo. A eso se le llama notificación por disponibilidad, o E/S basada en readiness, y es exactamente lo que ofrecen select, poll y epoll.

Qué significa “listo”: la cola de espera bajo cada fd

Aquí conviene mirar desde el kernel, porque “listo” tiene una definición precisa. Un socket está listo para leer cuando su búfer de recepción contiene bytes, o un fin de conexión, o un error; está listo para escribir cuando su búfer de envío tiene hueco. Todo archivo que se pueda multiplexar implementa f_op->poll, cuya doble tarea es inscribir a quien espera en la cola del fd con poll_wait y devolver una máscara de disponibilidad actual.

/* lado del kernel: todo fd multiplexable expone f_op->poll */
static __poll_t mi_poll(struct file *f, struct poll_table_struct *pt)
{
	struct mi_dev *d = f->private_data;
	__poll_t mask = 0;

	poll_wait(f, &d->rwq, pt);           /* inscribe al que espera en la cola */
	if (hay_datos(d))
		mask |= EPOLLIN | EPOLLRDNORM;   /* legible ahora mismo */
	if (hay_hueco(d))
		mask |= EPOLLOUT | EPOLLWRNORM;  /* escribible ahora mismo */
	return mask;
}

Una llamada de multiplexación recorre todos los fds que le pasas, invoca el f_op->poll de cada uno para inscribirse en su cola y recoger la disponibilidad presente; si ninguno está listo, se duerme, y cualquier despertar en cualquiera de esas colas la revive. Sobre esta maquinaria común se apoyan por igual select, poll y epoll: la única diferencia entre ellos es lo eficientemente que gestionan esa inscripción, y de esa diferencia trata el resto del nivel.

flowchart TB
subgraph Un hilo por conexion
  A1[accept] --> T1[hilo 1 dormido en read]
  A1 --> T2[hilo 2 dormido en read]
  A1 --> T3[hilo N dormido en read]
end
subgraph Un solo hilo multiplexado
  L[bucle de eventos] -->|espera readiness| K[kernel vigila N fds]
  K -->|fd listo| L
end

select, poll y epoll: el mapa del nivel

Existen tres respuestas históricas a la pregunta de esperar sobre muchos fds, y el resto del nivel las recorre en orden de madurez. Las tres se apoyan en el mismo f_op->poll del kernel; se diferencian solo en cómo gestionan el conjunto de interés, y esa diferencia lo decide todo a escala grande.