Pourquoi poster un commentaire énervé à 1h du mat' ? (si tu es dans la tz de Paris)
Parce que c'est énervé mais pas méchant ; j'avoue réfléchir à deux fois si c'est méchant, mais si c'est juste du HS je poste.
C'est une I/O ça peut planter tenter de ne gérer que les cas que tu imagine c'est généralement en oublier un énorme paquet. Et en terme de complexité ça n'est pas forcément si incroyable que ça. Du moins ça peut l'être si ton design a était prévu pour.
Il faut gérer tous les cas d'erreur, bien sûr, mais là on parle de latence dans la réponse ; et sur la complexité, j'ai l'impression que vous avez tous des ressentis sur la théorie que devrait être cette gestion, mais vous oubliez que « Worse is better ». En fait, il y a incompréhension sur l'objectif : bien sûr que j'aimerais une GUI qui soit tip-top et ne laggue pas, mais posez-vous la question de pourquoi c'est toujours difficile de résoudre un problème qui a 20 ou 30 ans et n'en finit pas ?
Si non tu pourrais lui expliquer ce que tu es entrain de faire, ce qui plante, lui donner des billes pour savoir si c'est transitoire ou non...
Je sais pas qui sont tes utilisateurs... si c'est transitoire, il faut... attendre, il n'y a rien d'autre à faire (comment pourrais-tu indiquer « ça va arriver dans 1 minute » ? Tu n'es pas devin !), et si c'est permanent, c'est que le feedback est bloqué pour une raison à la con (perte d'état intermédiaire que j'expliquais plus haut), et il faut corriger ça, parce qu'il n'existe pas de super heuristique sur « j'ai pas de feedback depuis X temps donc il faut abandonner » (pour info, dans TCP c'est 30 jours environ et c'est très bien comme ça).
Donc au lieu de faire en sorte que les UI restent réactives donnent des info à leur utilisateurs, il faut qu'ils investiguent eux-même d'où vient ton freeze, qu'ils regardent toutes les I/O de leur machine et potentiellement de leur réseau et corrigent le problème.
Mais si ton appli est capable d'avoir des infos, pourquoi elle freeze ? Quand l'appli freeze, c'est qu'elle est en attente sans en savoir plus. Que veux-tu dire à l'utilisateur qui permettra à lui de changer la situation, quand tu es en attente d'une machine à l'autre bout du réseau ? Mon point de vue c'est de vous demander de pousser la réflexion plus loin que la première étape qui est le feedback visuel, en se demandant ce que ça va changer à l'issue de la tâche qu'est en train d'effectuer l'utilisateur.
Tant pis si tu es sur un wifi publique ou si ta connexion est mauvaise (réseau mobile hors jolies 4 ou 5G ou alors ligne physique mais en défaut sur le moment) ?
Si ta connexion est lente, c'est quoi ton issue ? Attendre ou te barrer. J'ai jamais été contre « se barrer » dans mes commentaires plus haut, si c'est pour définitivement abandonner. Ce qui est un constat d'échec. Et dans l'autre cas, il faut... attendre.
[^] # Re: 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é à 2.
Parce que c'est énervé mais pas méchant ; j'avoue réfléchir à deux fois si c'est méchant, mais si c'est juste du HS je poste.
Il faut gérer tous les cas d'erreur, bien sûr, mais là on parle de latence dans la réponse ; et sur la complexité, j'ai l'impression que vous avez tous des ressentis sur la théorie que devrait être cette gestion, mais vous oubliez que « Worse is better ». En fait, il y a incompréhension sur l'objectif : bien sûr que j'aimerais une GUI qui soit tip-top et ne laggue pas, mais posez-vous la question de pourquoi c'est toujours difficile de résoudre un problème qui a 20 ou 30 ans et n'en finit pas ?
Je sais pas qui sont tes utilisateurs... si c'est transitoire, il faut... attendre, il n'y a rien d'autre à faire (comment pourrais-tu indiquer « ça va arriver dans 1 minute » ? Tu n'es pas devin !), et si c'est permanent, c'est que le feedback est bloqué pour une raison à la con (perte d'état intermédiaire que j'expliquais plus haut), et il faut corriger ça, parce qu'il n'existe pas de super heuristique sur « j'ai pas de feedback depuis X temps donc il faut abandonner » (pour info, dans TCP c'est 30 jours environ et c'est très bien comme ça).
Mais si ton appli est capable d'avoir des infos, pourquoi elle freeze ? Quand l'appli freeze, c'est qu'elle est en attente sans en savoir plus. Que veux-tu dire à l'utilisateur qui permettra à lui de changer la situation, quand tu es en attente d'une machine à l'autre bout du réseau ? Mon point de vue c'est de vous demander de pousser la réflexion plus loin que la première étape qui est le feedback visuel, en se demandant ce que ça va changer à l'issue de la tâche qu'est en train d'effectuer l'utilisateur.
Si ta connexion est lente, c'est quoi ton issue ? Attendre ou te barrer. J'ai jamais été contre « se barrer » dans mes commentaires plus haut, si c'est pour définitivement abandonner. Ce qui est un constat d'échec. Et dans l'autre cas, il faut... attendre.