XIO: fatal IO error 11 (Resource temporarily unavailable) on X server ":0" after 235 requests (235 known processed) with 0 events remaining

Question

Yes other people have asked this question before, but not in the same context or to my satisfaction. So, here goes::

I am writing an application using python, the program using pygame (ergo opengl) to display the graphics. The graphics are generated in the program itself (so no directory issues whatsoever).

The application also needs to access the input parallely from a user. To achieve this I use a multiprocessing block with a pipe and read the input key using pygame event loop. The below code runs in a loop. The first loop iteration works fine, but on the 2nd iteration I am thrown that XIO error.

   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()

I am a little perplexed at how this error occurs, what are the internals in XIO that cause it. None of the other answers actually explain the root cause of this error. Considering it works fine as a single process application, the multiprocessing module is closing some IO channel (the input registered object, the display object or the event loop) or opening some unnecessary channels. How can I decipher what exactly is causing this XIO error?

Answer 1

Not necessarily a real answer, but I would not use multiprocessing to parallelize access to sockets like the connection to the X server. That looks like a bad idea. Use regular threads instead.

Be aware that multiprocessing is a hack based (sometimes) on forking, so what exactly occurs with a forked socket when both the parent and the child try to access it... is random mixed garbage.

EDIT: the reason is that both forked sockets are still the "same end" of the socket, with the X server holding on the "other end". When the X server wants to send a message, it writes, say, 100 bytes on the socket. But if you're unlucky, the forked process 1 reads the first 50 bytes and the forked process 2 reads the remaining 50 bytes. Each process is unexpectedly getting only a random part of the message. They will each complain that the X server is sending nonsense.