ton process qui est sense afficher une video est stoppe.
euh ? oui, mais ce n'est pas forcément grave. Ce n'est important que si ton process ne tient pas ses deadlines dans tous les autres cas...
Si tu veux anticipé des brusques indisponnibilités du système, tu utilises des caches. Un asynch io fait le boulot que tu veux faire : lire le bloc suivant pendant que tu traites le bloc courant.
Les thread ne sont pas plus efficaces (sauf lors d'application vraiement interractive et qui ont des phases lente à faire laguer l'affichage comme certain client mail).
Ils sont juste plus facile à coder. L'exemple typique sont les serveurs multi-threadé qui enfle à chaque nouveau connecté. Si TUX (serveur web kernel plus rapide encore que khttpd) déchire tant c'est bien parce que il n'utilise pas un thread par connection !
[^] # 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é à 1.
euh ? oui, mais ce n'est pas forcément grave. Ce n'est important que si ton process ne tient pas ses deadlines dans tous les autres cas...
Si tu veux anticipé des brusques indisponnibilités du système, tu utilises des caches. Un asynch io fait le boulot que tu veux faire : lire le bloc suivant pendant que tu traites le bloc courant.
Les thread ne sont pas plus efficaces (sauf lors d'application vraiement interractive et qui ont des phases lente à faire laguer l'affichage comme certain client mail).
Ils sont juste plus facile à coder. L'exemple typique sont les serveurs multi-threadé qui enfle à chaque nouveau connecté. Si TUX (serveur web kernel plus rapide encore que khttpd) déchire tant c'est bien parce que il n'utilise pas un thread par connection !
"La première sécurité est la liberté"