• [^] # Re: Pont

    Posté par . En réponse à la dépêche XCB : bientôt la version 1. Évalué à 2.

    Le principe, c'est qu'un appel xlib est bloquant. Donc pendant ce temps la, l'appli client appelante est bloquee. Pas de rafraichissement, du temps qu'elle pourrait utiliser a autre chose, etc. Avec XCB, cette meme appli n'est plus bloquee puisque les appels sont asynchrones. Elle peut faire autre chose en attendant le resultat.
    Et bien avec Xlib, le truc pas top, c'est que c'est le programmeur lui-meme qui doit gerer le multithreading pour pallier ce probleme. Alors que XCB etant asynchrone, je pense que la seule maniere de gerer ca correctement est de laisser la librairie gerer ca.

    Je suis pas expert X donc dites-moi si j'ai rien compris. Si on suit mon raisonnement, utiliser le pont xlib ne devrait pas apporter tant que ca puisque pour des raisons de compabilites, les appels doivent etre bloquants aussi ? Bon, j'ai l'impression que je m'embrouille.
    Plus ou moins. En fait, utiliser XCL permet de remplacer XLib par la meme interface (les signatures de fonctions sont identiques).
    L'avantage est que les programmes ecrits pour XLib peuvent continuer a marcher avec XCL sans les recompiler. Mais, je ne pense pas que l'on soit oblige de rendre ces appels "pseudo-bloquants". Cela doit marcher meme si l'on ne rend pas bloquants ces appels, sauf si l'application repose sur ce mecanisme de blocage pour une raison ou pour une autre (mais je ne vois pas laquelle).
    Les applications qui vont le mieux tirer parti de cette librairie seront forcement celles qui l'utiliseront en natif.