Skip to main content

Module shared

Module shared 

Source
Expand description

Usage multi-thread d’io_uring (Temps 3e). Sous-module air-sys-syscall::io_uring::shared. Repose sur l’invariant ADR-022 Décision 6 (IoUring est Send mais !Sync), sur SETUP_SQPOLL (Temps 1), ATTACH_WQ (Temps 3a) et msg_ring (Temps 2c). Aucun register opcode propre.

Référence normative : docs/specs/layer-0/io-uring-3e-shared.md.

§Le point de départ : Send mais pas Sync

Le protocole d’ordering du Temps 1 (§3.2) synchronise userspace ↔ kernel, pas userspace ↔ userspace : têtes/queues SQ/CQ et slab S1 ne sont pas protégés contre des accès userspace concurrents. Le !Sync d’IoUring interdit par typage le partage accidentel d’un ring (prouvé par un doctest compile_fail sur LockedIoUring). Trois réponses, par ordre de préférence Air :

  1. Thread-per-core (§2, recommandé) — un IoUring par thread (SINGLE_ISSUER | DEFER_TASKRUN), aucun verrou ; communication par msg_ring. Aucun type nouveau : usage direct d’IoUring, déplacé (Send) dans son thread. RingPool organise N tels rings.
  2. LockedIoUring (§3) — un ring partagé derrière un verrou (Send + Sync). Simple, mais le verrou est un point de contention.
  3. SqpollIoUring (§5) — un thread kernel scrute la SQ (latence vs CPU).

Structs§

LockedIoUring
Un IoUring partagé entre threads derrière un verrou interne (Send + Sync). Le verrou sérialise les accès userspace au SQ/CQ/slab ; le protocole d’ordering userspace↔kernel du Temps 1 reste inchangé dessous.
RingHandle
Référence à un ring pair, utilisable comme cible de msg_ring (IoUring::submit_message_ring_data_to). Porte le FD du ring pair (valide tant que ce ring vit dans son thread — l’appelant garantit sa vivacité).
RingPool
Assistant thread-per-core : crée N IoUring cohérents en partageant le pool io-wq (ATTACH_WQ, Temps 3a) — le nombre total de threads workers kernel est borné quel que soit N (crucial sur matériel modeste, Pi 4) — et en enregistrant les ring fds (Temps 3a) pour le routage msg_ring.
SqpollIoUring
IoUring créé avec IORING_SETUP_SQPOLL : un thread kernel scrute la SQ. En régime établi, la soumission ne fait aucun io_uring_enter (juste la publication release) → latence minimale.