Issue 5573: multiprocessing Pipe poll() and recv() semantics. (original) (raw)

Issue5573

Created on 2009-03-26 19:38 by mallyvai, last changed 2022-04-11 14:56 by admin. This issue is now closed.

Messages (3)
msg84204 - (view)	Author: Vaibhav Mallya (mallyvai)	Date: 2009-03-26 19:38
Python 2.6.1 (r261:67515, Mar 22 2009, 05:39:39) [GCC 4.2.4 (Ubuntu 4.2.4-1ubuntu4)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> from multiprocessing import Pipe >>> parent, child = Pipe() >>> parent.send(1) >>> parent.close() >>> print child.recv() 1 >>> print child.poll() True >>> print child.recv() Traceback (most recent call last): File "", line 1, in EOFError We have to use both poll() and recv() to determine whether or not the connection was actually closed. Better behavior might be returning True on poll() only if the next recv() on that end of the pipe will work without an error. There may not be a way to guarantee this, but it would be useful if the documentation was clarified either way. uname -a: Linux mememy 2.6.24-23-generic #1 SMP Thu Feb 5 15:00:25 UTC 2009 i686 GNU/Linux Compiled Python 2.6.1 from source.
msg84255 - (view)	Author: Vaibhav Mallya (mallyvai)	Date: 2009-03-27 06:58
On second thought, it seems like it shouldn't make sense. This forces a destructive check. Suppose we do child.poll() and then child.recv() but it's legitimate data; that data will be removed from the queue even if we just wanted to check if the pipe was alive. This seems like it shouldn't have to happen. I'm unfamiliar with the lower level workings of sockets; is this destructive checking behavior forced by the socket internals? Is it standard?
msg119502 - (view)	Author: Ask Solem (asksol)	Date: 2010-10-24 09:09
I don't know about the socket internals, but I find the behavior acceptable. It may not be feasible to change it now anyway, as there may be people already depending on it (e.g. not handling errors occurring at poll)