[issue33688] asyncio child watchers aren't fork friendly

Change by Zac Medico : -- nosy: +zmedico ___ Python tracker <https://bugs.python.org/issue33688> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue22087] asyncio: support multiprocessing (support fork)

Change by Zac Medico : -- nosy: +zmedico ___ Python tracker <https://bugs.python.org/issue22087> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue21998] asyncio: support fork

Zac Medico added the comment: I'm not sure about possible use cases that might conflict with this approach, but using a separate event loop for each pid seems very reasonable to me, as follows: _default_policy = asyncio.get_event_loop_policy() _pid_loop = {} class MultiprocessingP

[issue29373] subprocess.Popen os.close(p2cread) in _execute_child can cause garbage collection of self.stdout to close a reused file descriptor

Zac Medico added the comment: Actually, os.close(p2cread) closes a different file descriptor than c2pread, so my analysis is not correct. I don't know the precise cause of the EBADF error that I have observed. I suppose it could be some other code closing a file descriptor that belongs

[issue29373] subprocess.Popen os.close(p2cread) in _execute_child can cause garbage collection of self.stdout to close a reused file descriptor

New submission from Zac Medico: In Popen _execute_child method, os.close(p2cread) closes a file descriptor which is referenced by self.stdout with closefd=True, created by this code: self.stdout = io.open(c2pread, 'rb', bufsize) When self.stdout is finally garbage collected, it c

[issue28682] Bytes support in os.fwalk()

Changes by Zac Medico : -- nosy: +zmedico ___ Python tracker <http://bugs.python.org/issue28682> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue14988] _elementtree: Raise ImportError when importing of pyexpat fails

Changes by Zac Medico : -- nosy: +zmedico ___ Python tracker <http://bugs.python.org/issue14988> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue5380] pty.read raises IOError when slave pty device is closed

Zac Medico added the comment: This issue no longer appears to be a problem for my purposes, since it seems that array.fromfile() does not lose any data as long as the input file is opened in unbuffered mode (I use fdopen with 0 for the bufsize argument

[issue5380] array.fromfile() on master pty raises IOError when slave pty device is closed

New submission from Zac Medico : With python-3.0, array.fromfile() raises an IOError when reading from a master pty device after the slave device has been closed. This causes remaining data that had been written to the slave device to be lost. I have observed this problem with python-3.0.1 on

[issue5334] array.fromfile() fails to insert values when EOFError is raised

Zac Medico added the comment: Thanks for the patch. It works for me. -- components: +Library (Lib) -Extension Modules versions: -Python 3.1 ___ Python tracker <http://bugs.python.org/issue5

[issue5334] array.fromfile() fails to insert values when EOFError is raised

Changes by Zac Medico : Removed file: http://bugs.python.org/file13143/fromfile_eof.py ___ Python tracker <http://bugs.python.org/issue5334> ___ ___ Python-bugs-list m

[issue5334] array.fromfile() fails to insert values when EOFError is raised

Changes by Zac Medico : Added file: http://bugs.python.org/file13144/fromfile_eof.py ___ Python tracker <http://bugs.python.org/issue5334> ___ ___ Python-bugs-list mailin

[issue5334] array.fromfile() fails to insert values when EOFError is raised

New submission from Zac Medico : With python-3.0, array.fromfile() fails to insert values when EOFError is raised. I ran the attached test case with python-3.0.1 and got the same result on both linux and windows. With python-2.x, the values are properly inserted despite an EOFError, as the