Ce que tu décris s'appelle les acces asynchrones ou non bloquant (asyncIO). Il me semble que la glibc sait faire ça depuis longtemps elle même et que linux 2.4 le prends en charge maintenant commeun grand.
Il est donc parfaitement inutile de programmer un thread pour ça.
De plus, lors d'acces io, si le temps est trop long, le scheduler peut décider de donner la main à un autre process (cela se voit facilement avec l'utilisation d'un lentissime printf). Tu ne perds donc aucun cycle.
Si ta machine ne fait qu'une seule tache, un monothread sans io non bloquante étant bloqué à chaque io, tu perds des perf sur ce process-là uniquement. Mais globalement, ta machine peut faire d'autres trucs. Il n'y a pas de gaspillage.
Si tu veux augmenter les perf c'est-à-dire parraléliser acces disque et calcul, et bien, les io asynchrones ou non bloquantes sont faites pour ça !
[^] # Re: MplayerXP fork de MPlayer avec support des threads
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Document sur le développement de mplayer. Évalué à 3.
Il est donc parfaitement inutile de programmer un thread pour ça.
De plus, lors d'acces io, si le temps est trop long, le scheduler peut décider de donner la main à un autre process (cela se voit facilement avec l'utilisation d'un lentissime printf). Tu ne perds donc aucun cycle.
Si ta machine ne fait qu'une seule tache, un monothread sans io non bloquante étant bloqué à chaque io, tu perds des perf sur ce process-là uniquement. Mais globalement, ta machine peut faire d'autres trucs. Il n'y a pas de gaspillage.
Si tu veux augmenter les perf c'est-à-dire parraléliser acces disque et calcul, et bien, les io asynchrones ou non bloquantes sont faites pour ça !
"La première sécurité est la liberté"