XIO: fatal IO error 11 (Ressource temporairement non disponible) sur le serveur X “:0,” après 235 demandes (235 connu traitées) avec 0 événements

Oui, d'autres personnes ont posé cette question avant, mais pas dans le même contexte ou à ma satisfaction. Donc, ici, va::

Je suis en train d'écrire une application à l'aide de python, le programme à l'aide de pygame (ergo opengl) pour afficher le graphique. Les graphiques sont générés dans le programme lui-même (donc pas de problèmes de répertoires que ce soit).

L'application a également besoin d'accéder à l'entrée parallèle à partir d'un utilisateur. Pour réaliser cela, j'utilise un multitraitement bloc avec un tuyau et de lire la clé d'entrée à l'aide de pygame boucle d'événements. Le code ci-dessous s'exécute dans une boucle. La première itération de boucle fonctionne bien, mais sur la 2ème itération je me suis levée que XIO erreur.

   parent, child = Pipe(duplex=True)
   # this function draws the canvas
   switches, retOrient = self.drawCanvas(cond, count, dispSize, moves)
   # this function gets the user input in another thread - stage 1
   p = Process(target=userInput, args=(self.button, child) )
   p.start()
   b_press = parent.recv()
   parent.close()

def userInput(button, child):
    button_pressed = button.blockAndWait()
    child.send( "%s"%(button_pressed.keyname) )
    child.close()

Je suis un peu perplexe sur la façon dont cette erreur se produit, quelles sont les pièces internes de XIO qui en sont la cause. Aucune des autres réponses expliquer la cause de cette erreur. Considérant qu'il fonctionne bien comme un processus unique de l'application, le multitraitement module de fermeture quelques IO canal (l'entrée d'objet enregistré, l'affichage de l'objet ou de l'événement en boucle) ou de l'ouverture de certaines inutile canaux. Comment déchiffrer ce qui est exactement la cause de cette XIO erreur?

OriginalL'auteur knk | 2012-12-07

  1. 8

    Pas nécessairement une vraie réponse, mais je ne voudrais pas utiliser multiprocessing pour paralléliser les accès aux sockets comme la connexion au serveur X. Qui ressemble à une mauvaise idée. L'utilisation régulière des threads plutôt que.

    Être conscient que multiprocessing est un hack de base (parfois) sur la fourche, donc exactement ce qui se produit avec une fourche prise quand à la fois le parent et l'enfant, essayez d'y accéder... est aléatoire mixte des ordures.

    EDIT: la raison en est que les deux fourches sockets sont toujours le "même" de la socket du serveur X en s'appuyant sur le "l'autre bout". Lorsque le serveur X veut envoyer un message, il écrit, disons, 100 octets sur le socket. Mais si vous êtes malchanceux, la fourche processus 1 lit les 50 premiers octets et la fourche processus 2 lit la participation restante de 50 octets. Chaque processus est de façon inattendue de n'avoir qu'une partie aléatoire du message. Chacun d'eux se plaignent que le serveur X est l'envoi de non-sens.

    +1. De nombreux développeurs ne se rendent pas compte que X11 est construit sur des sockets, donc même si ils ne savent pas utiliser directement une prise sur les deux côtés d'une fork, ils s'attendent à être en mesure d'utiliser le même X des deux côtés. (Cela dit, le plus populaire de la non-prise Interfaces graphiques ne fonctionnent pas avec multiprocessing, pour différentes raisons—pas de CoreFoundation dans la fourche des processus sur Mac, pas de fork et donc pas de partage de par processus des ressources comme le GDI sur Windows...)
    1. Python les threads ne sont pas exactement simultanées et c'est la raison pour laquelle je suis à l'aide de multitraitement. 2. Je pensais le long des lignes d'isoler les effets et l'ouverture de canaux (sockets ou autrement) par threads (ou processus). Ici, je ne sais pas les canaux qui sont à l'origine des problèmes d'isoler l'effet. Je m'attendais à un peu de lumière le long de cet itinéraire. Aussi, pourriez-vous préciser pourquoi directement à l'aide d'un support sur les deux côtés de la fourche est une mauvaise idée
    Édité ma réponse. Pour résoudre votre problème, vous devez faire très attention à ce que toute utilisation de multiprocessing est limitée à la non-GUI parties du programme. En d'autres termes, c'est bien d'utiliser multiprocessing lorsque vous voulez faire de calcul intensif des tâches, mais vous ne devez utiliser l'API fournie dans le multiprocessing module pour la communication entre les différentes parties. Tous les appels à pygame doit être fait à partir du processus principal.

    OriginalL'auteur Armin Rigo