• [^] # Re: Aucun I/O dans le fil d'exécution principal est irréaliste

    Posté par . En réponse au journal GNOME avec un scheduler temps réel. Évalué à 5.

    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 ?

    Ok en fait on ne s'est pas compris.

    Le freeze c'est le fait qu'une interface graphique ne réponde plus.

    Tu peux très bien organiser ton code pour que le fil d'exécution qui gère l'interface ne fasse que la gestion de l'UI et interactions avec le gros du logiciel. C'est l'architecture qui était généralisée sur BeOS (d'où le commentaire plus bas). C'est ça qui est reproché.

    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.

    Déjà avoir systématiquement ce retour ce serait énorme. C'est ce feedback qui permet à l'utilisateur de mieux comprendre ce qui se passe et pourquoi des choses prennent du temps. Et ça lui permet de faire des choix plus éclairé que ce que son imagination va donner.

    Ensuite la logique voudrait que tu ne puisse pas modifier un traitement en cours, uniquement l'annuler. Mais c'est un pas bien plus compliqué à mettre en place.

    https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll