(Note: This issue only happens on linux - on Windows things work fine.)

Please see the attached script.

The script creates a process (TestProcess()). That process runs and
creates a sub-process (TestSubProcess()). When TestSubProcess tries to
access a Queue created by TestProcess, the .get() call fails with the
following stack trace:

Process Process-1:1:
Traceback (most recent call last):
  File "/opt/python2.6/lib/python2.6/multiprocessing/process.py", line
231, in _bootstrap
    self.run()
  File "/opt/python2.6/lib/python2.6/multiprocessing/process.py", line
88, in run
    self._target(*self._args, **self._kwargs)
  File "queue_test.py", line 7, in TestSubProcess
    item = q.get()                        # Fails with IOError if queue
created in TestProcess
  File "/opt/python2.6/lib/python2.6/multiprocessing/queues.py", line
91, in get
    res = self._recv()
IOError: [Errno 9] Bad file descriptor

If the same queue is created by main (top level), TestSubProcess
accesses it with no errors. This behavior can be stimulated by
uncommenting the q = multiprocessing.Queue() line in TestProcess.


Tested using:
Python 2.6.1 (r261:67517, Dec  4 2008, 16:51:00) [MSC v.1500 32 bit
(Intel)] on win32
(Installed using binary installer, windows XPSP2)

*No problems*

Python 2.6.1 (r261:67515, Jan  6 2009, 15:23:19) [GCC 4.2.4 (Ubuntu
4.2.4-1ubuntu3)] on linux2
(Compiled from source due to ubuntu 8.04 (Hardy) not having python2.6 yet)

*Fails on q.get() in TestSubProcess*

Also reproduced in Python3.0 on OSX 10.5

Quick note: Have tracked this down to what appears to be buggy behaviour
on the part of os.pipe() when called from within a Process.

First invocation of os.pipe() in a Process returns (0,x) - stdin(?)
resulting in the 'bad file descriptor' error.

Interactive prompt test follows:

>>> import multiprocessing as MP, os
>>> def r():  print os.pipe(), os.pipe(), os.pipe()
... 
>>> r()
(9, 10) (11, 12) (13, 14)
>>> MP.Process(target=r).start()
(0, 15) (16, 17) (18, 19)
>>> MP.Process(target=r).start()
(0, 15) (16, 17) (18, 19)

Issue 5313 seems to be the culprit.

Patch attached to issue 5313, please review.

Committed in r73708 on trunk