This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: multiprocessing Pipe poll() and recv() semantics.
Type: behavior Stage:
Components: Documentation, Library (Lib) Versions: Python 2.6
process
Status: closed Resolution: not a bug
Dependencies: Superseder:
Assigned To: jnoller Nosy List: asksol, georg.brandl, jnoller, mallyvai
Priority: normal Keywords:

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 "<stdin>", line 1, in <module>
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) (Python committer) 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)
History
Date User Action Args
2022-04-11 14:56:46adminsetgithub: 49823
2010-11-02 15:33:31asksolsetstatus: open -> closed
resolution: not a bug
2010-10-24 09:09:43asksolsetmessages: + msg119502
2010-08-27 12:52:06asksolsetnosy: + asksol
2009-03-29 14:35:15jnollersetpriority: normal
2009-03-27 06:59:06mallyvaisetmessages: + msg84255
2009-03-26 19:44:59jnollersetassignee: georg.brandl -> jnoller
2009-03-26 19:44:00mallyvaisetnosy: + jnoller
2009-03-26 19:38:31mallyvaicreate