Je rêve d'autre chose aussi, aucun accès IO dans le fil d'exécution principal du rendu du shell,
Je ne pense pas que ça apporte du bien : ça ne fait que repousser le problème. Soit tu n'avais pas réellement besoin de cette I/O, dans ce cas il faut corriger le code, soit tu en avais vraiment besoin et tu vas inventer la roulette à la MacOS ou équivalent. Le truc c'est que tu ne géreras jamais tous les cas possibles où t'as besoin d'I/O, car t'auras toujours des I/O abstraites derrières 3 couches à travers 10 appels de fonction que tu ne connais pas. Donc ça bloquera, buguera, ou autre.
De toutes façons, les systèmes qui veulent ainsi cacher les latences sont « mous » dans le sens où en voulant cacher le feedback, on perd tout lien avec le besoin réel de resource (ici en I/O) derrière : ya le même problème sur le Web avec tout le JS qui attend des resources réseau sur une connexion lente, et c'est tout moisi quand tout est (presque) géré par le JS lui-même avec masse d'artifice pour te faire attendre. C'est même un principe « physique » si on peut dire : c'est la base des circuits en boucle fermés, dans lesquels tu rajouterais de la capacité (pour les électroniciens, mettre de la capa ça « résout » magiquement tout les problèmes ; mais en fait ça en ajoute plein d'autres). C'est pareil en réseau avec l'ajout de buffer, en algorithmique en ajoutant des caches (de la mémoire), etc.
# Aucun I/O dans le fil d'exécution principal est irréaliste
Posté par benoar . En réponse au journal GNOME avec un scheduler temps réel. Évalué à 5.
Je ne pense pas que ça apporte du bien : ça ne fait que repousser le problème. Soit tu n'avais pas réellement besoin de cette I/O, dans ce cas il faut corriger le code, soit tu en avais vraiment besoin et tu vas inventer la roulette à la MacOS ou équivalent. Le truc c'est que tu ne géreras jamais tous les cas possibles où t'as besoin d'I/O, car t'auras toujours des I/O abstraites derrières 3 couches à travers 10 appels de fonction que tu ne connais pas. Donc ça bloquera, buguera, ou autre.
De toutes façons, les systèmes qui veulent ainsi cacher les latences sont « mous » dans le sens où en voulant cacher le feedback, on perd tout lien avec le besoin réel de resource (ici en I/O) derrière : ya le même problème sur le Web avec tout le JS qui attend des resources réseau sur une connexion lente, et c'est tout moisi quand tout est (presque) géré par le JS lui-même avec masse d'artifice pour te faire attendre. C'est même un principe « physique » si on peut dire : c'est la base des circuits en boucle fermés, dans lesquels tu rajouterais de la capacité (pour les électroniciens, mettre de la capa ça « résout » magiquement tout les problèmes ; mais en fait ça en ajoute plein d'autres). C'est pareil en réseau avec l'ajout de buffer, en algorithmique en ajoutant des caches (de la mémoire), etc.