Alban’s blog

Lucas a eu un problème avec un bout de code en Ruby: en gros, ça se bloque lorsqu’on essaie de lire un fichier de /proc. Les autres fichiers ne font pas bloquer le programme. Le problème apparait uniquement sur les noyaux linux 2.6. Les 2.4 n’ont pas ce problème.

A coup de strace, on découvre que les user threads de Ruby utilisent l’appel système select afin de faire des I/O non bloquants entre les threads. En effet, comme les threads sont implémentés sans aucun support du noyau, si un thread se trouve bloqué dans un appel système bloquant, les autres threads le sont aussi, contrairement aux vrais threads. L’utilisation de l’appel système select évite cela.

On pourrait se dire que les développeurs de Ruby auraient pu utiliser l’option O_NONBLOCK pour les appels d’I/O pour éviter qu’ils soient bloquants. Mais cela ne permet pas de faire de l’attente passive.

J’ai écrit un bout de code en C qui isole un peu plus le problème. On observe alors que c’est bien l’appel système select qui pose problème: le comportement de select ne correspond pas à ce qui est attendu pour certains fichiers de /proc (il s’agit de loadavg, uptime, meminfo, version, hardware, stram, devices, filesystems, cmdline, locks et execdomains). D’autres fichiers de /proc semblent marcher (par exemple, cpuinfo, partitions, mounts…).

Avec Matthieu, on a cherché d’où cela venait et pourquoi le 2.6 a un comportement différent du 2.4. Le code de l’appel système select se trouve dans fs/select.c. Celui-ci appelle le code de poll si le descripteur de fichier en question comporte une telle méthode (file->f_op->poll). Après quelques tests, il semble que /proc/uptime possède une méthode poll mais je n’ai pas trouvé son code…

Une page trouvée par Google rapporte une discussion sur l’utilité ou non de supporter l’appel système select et poll pour les fichiers de /proc.

J’ai finalement posé la question sur la LKML. En espérant avoir une réponse…

Et vous, qu’en pensez-vous?