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.
Non, ce que je decris c'est une methode naturelle d'utiliser au mieux les perfs, que ta machine soit SMP ou pas, le soft fera au mieux (rien n'interdit d'utiliser les async I/O dans un soft multithread, c'est meme conseille), tout en simplifiant le design.
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.
Exact, ce qui revient a dire que pendant que l'acces I/O s'effectue, ton process qui est sense afficher une video est stoppe.
Hors le but ici ce n'est pas d'economiser au maximum des cycles, c'est d'avoir une video qui s'affiche de maniere fluide, et de faire du boulot en avance en prevision de problemes futurs.
Si les threads s'imposent de plus en plus comme le modele a suivre c'est pas pour rien, c'est definitevement plus efficace que le modele monothread.
[^] # Re: MplayerXP fork de MPlayer avec support des threads
Posté par pasBill pasGates . 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.
Non, ce que je decris c'est une methode naturelle d'utiliser au mieux les perfs, que ta machine soit SMP ou pas, le soft fera au mieux (rien n'interdit d'utiliser les async I/O dans un soft multithread, c'est meme conseille), tout en simplifiant le design.
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.
Exact, ce qui revient a dire que pendant que l'acces I/O s'effectue, ton process qui est sense afficher une video est stoppe.
Hors le but ici ce n'est pas d'economiser au maximum des cycles, c'est d'avoir une video qui s'affiche de maniere fluide, et de faire du boulot en avance en prevision de problemes futurs.
Si les threads s'imposent de plus en plus comme le modele a suivre c'est pas pour rien, c'est definitevement plus efficace que le modele monothread.