multiprocessing.process using os.close(sys.stdin.fileno) instead of sys.stdin.close() #49563
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
assignee = None closed_at = <Date 2009-06-30.17:13:43.818> created_at = <Date 2009-02-19.05:21:10.032> labels =  title = 'multiprocessing.process using os.close(sys.stdin.fileno) instead of sys.stdin.close()' updated_at = <Date 2009-06-30.17:13:43.817> user = 'https://bugs.python.org/grahamd'
activity = <Date 2009-06-30.17:13:43.817> actor = 'jnoller' assignee = 'jnoller' closed = True closed_date = <Date 2009-06-30.17:13:43.818> closer = 'jnoller' components =  creation = <Date 2009-02-19.05:21:10.032> creator = 'grahamd' dependencies =  files = ['13704', '14402'] hgrepos =  issue_num = 5313 keywords = ['patch'] message_count = 12.0 messages = ['82457', '82579', '86024', '89195', '89198', '89199', '89205', '89522', '89523', '89529', '89900', '89943'] nosy_count = 5.0 nosy_names = ['OG7', 'jnoller', 'grahamd', 'ptn', 'i000'] pr_nums =  priority = 'low' resolution = 'fixed' stage = None status = 'closed' superseder = None type = None url = 'https://bugs.python.org/issue5313' versions = ['Python 2.6', 'Python 3.0']
The text was updated successfully, but these errors were encountered:
In multiprocessing.process it contains the code:
def _bootstrap(self): .... if sys.stdin is not None: try: os.close(sys.stdin.fileno()) except (OSError, ValueError): pass
This code should probably be calling sys.stdin.close() and not
The code as is will fail if sys.stdin had been replaced with an alternate
Joshua Judson Rosen to python-list
Jesse Noller <firstname.lastname@example.org> writes:
My guess would be: because it's also possible for sys.stdin to be a
There's a general guideline, inherited from C, that one should ensure
So, if you call sys.stdin.close() in the child-process in
You can expect similar issues with just about /any/
As such, I'd recommend against just using .close(); you might use
I guess you could try calling that an
I believe I am the edge-case. I've written a minimalist python
to reproduce run papy_gui.py and type: >>> from math import sqrt >>> from multiprocessing import Pool >>> p = Pool() >>> print p <multiprocessing.pool.Pool object at 0xb723738c> >>> p.map(sqrt, [1,2,3]) <<no more output ever>>
Worth noting is that Python documentation in:
Note File-like objects which do not have a real file descriptor should
So, if sys.stdin is replaced with a file like object, then the code
At the moment the code doesn't check for AttributeError which is what is
""" >>> import StringIO >>> s=StringIO.StringIO("xxx") >>> s.fileno() Traceback (most recent call last): File "<stdin>", line 1, in <module> AttributeError: StringIO instance has no attribute 'fileno' """
Thus error propagates. The better check though would be to use:
def _bootstrap(self): .... if sys.stdin is not None and hasattr(sys.stdin, "fileno"): try: os.close(sys.stdin.fileno()) except (OSError, ValueError): pass
That is, only actually call fileno() if it is present.
This would solve the problem for the original reported issue by making
This change wouldn't necessarily solve other peoples related issues
Closing the stdin fd without closing the stdin file is very dangerous.
Closing stdin is useful to let the parent be alone in reading from it.
The "double flush" case is impossible to handle in general. It's the
So that code in _bootstrap should be:
Attached is a patch which calls close() first, and then attempts to close
This is just a thought, feedback welcome - right now this allows this
Please do this:
--- a/multiprocessing/process.py +++ b/multiprocessing/process.py @@ -225,7 +225,8 @@ class Process(object): self._children = set() self._counter = itertools.count(1) try: - os.close(sys.stdin.fileno()) + sys.stdin.close() + sys.stdin = open(os.devnull) except (OSError, ValueError): pass _current_process = self
One shouldn't close the fileno after the file has been closed. The
The open(os.devnull) bit is both so that no one tries to do anything
On Fri, Jun 19, 2009 at 11:55 AM, OG7<email@example.com> wrote:
Fair enough, I was worried a bit about skipping the