Kristján Valur Jónsson krist...@ccpgames.com added the comment:
I can't see how that patch has anything to do with it. The problem has been
present since at least 2.5. Your patch fixed it for timeout0.0 but left the
0.0 case still broken.
It comes from these lines in init_sockobject:
{
Kristján Valur Jónsson krist...@ccpgames.com added the comment:
Please see issue 11721 where I was commenting on the same.
I don't think the documentation makes it clear that socket.gettimeout() can be
incorrect (i.e. return None when the socket is non-blocking).
I also don't think there is a
Antoine Pitrou pit...@free.fr added the comment:
I also don't think there is a portable way to detect the NBIO attribute
of a socket, so we still have a case of socket.gettimeout() not
accurately reflecting the blocking state of the socket
Which case?
I personally think that this logic
Kristján Valur Jónsson krist...@ccpgames.com added the comment:
socket.defaulttimeout(None)
s = socket.socket()
s.settimeout(0) #nonblocking
s.bind()
s2, a = s.accept()
print s2.gettimeout() #prints ´none´, meaning blocking
s2.receive(10) #raises EWOULDBLOCK error, since internally it is
Antoine Pitrou pit...@free.fr added the comment:
socket.defaulttimeout(None)
s = socket.socket()
s.settimeout(0) #nonblocking
s.bind()
s2, a = s.accept()
print s2.gettimeout() #prints ´none´, meaning blocking
s2.receive(10) #raises EWOULDBLOCK error, since internally it is non-blocking
Daniel Stutzbach stutzb...@google.com added the comment:
I'm confused by the patch (ed0259230611). The patch comment and the NEWS item
state the returned socket is now always non-blocking but the code change adds
sock.setblocking(True).
--
nosy: +stutzbach
Kristján Valur Jónsson krist...@ccpgames.com added the comment:
Antoine, absolument. Please see attached file bug.py
As for a different patch, we should agree what behaviour should be expected. I
don't think it is possible to rely on some platform specific behaviour. This
is because it is
Antoine Pitrou pit...@free.fr added the comment:
Antoine, absolument. Please see attached file bug.py
Ah, thanks, I see. But this is not caused by this issue.
It seems to come from 12442ac3f7dd.
Instead we should simply define it for python, and in accordance to
established tradition,
Antoine Pitrou pit...@free.fr added the comment:
Ok, here is a patch which prefers the default timeout (if set) over fixing of
inherited flags. Tested under Linux, Windows, OpenSolaris.
--
Added file: http://bugs.python.org/file20278/nonblock3.patch
Martin v. Löwis mar...@v.loewis.de added the comment:
Ok, here is a patch which prefers the default timeout (if set) over fixing of
inherited flags. Tested under Linux, Windows, OpenSolaris.
This patch looks fine to me. Please also update the accept documentation
to explain the situation
Antoine Pitrou pit...@free.fr added the comment:
Ok, I committed the patch in r87768 and overhauled the timeout docs in r87769.
I'm not sure this should be backported (because of the very slight behaviour
change), so I'm closing.
--
keywords: -needs review
resolution: - fixed
stage:
Antoine Pitrou pit...@free.fr added the comment:
A new patch combining Ross' test with the simple approach from issue 976613.
Works under Linux, OpenSolaris and Windows.
--
Added file: http://bugs.python.org/file20257/nonblock2.patch
___
Python
Martin v. Löwis mar...@v.loewis.de added the comment:
I think this patch (nonblock2.patch) is wrong. If I have a non-blocking server
socket on *BSD, and do accept, with no default timeout: IIUC, under the patch,
I will get a blocking connection socket. However, according to the operating
Antoine Pitrou pit...@free.fr added the comment:
I think this patch (nonblock2.patch) is wrong. If I have a
non-blocking server socket on *BSD, and do accept, with no default
timeout: IIUC, under the patch, I will get a blocking connection
socket. However, according to the operating system
Antoine Pitrou pit...@free.fr added the comment:
Antoine Pitrou pit...@free.fr added the comment:
I think this patch (nonblock2.patch) is wrong. If I have a
non-blocking server socket on *BSD, and do accept, with no default
timeout: IIUC, under the patch, I will get a blocking
Martin v. Löwis mar...@v.loewis.de added the comment:
Well, either the defaulttimeout should have the priority over the parent
socket's settings (your argument in msg125135), or it shouldn't. I'm
fine with both, but I think any more complicated combination would end
up puzzling for the user
Antoine Pitrou pit...@free.fr added the comment:
I like the logic of Antoine's patch much better (basing this on
whether the listening socket had a timeout). I wonder whether it's
correct though if there is a defaulttimeout: shouldn't it then leave
the timeout on the socket instead?
Indeed,
Antoine Pitrou pit...@free.fr added the comment:
Issue 976613 (duplicate) has a very simple patch, will see if it's sufficient.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7995
___
Antoine Pitrou pit...@free.fr added the comment:
I've tried the patch under OpenSolaris and the test fails (EAGAIN),
meaning that accept() semantics there are the same as under BSD:
==
ERROR: testInheritFlags
Ross Lagerwall rosslagerw...@gmail.com added the comment:
OK try this one, it's now opt-out.
--
Added file: http://bugs.python.org/file20222/7995_v3.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7995
Antoine Pitrou pit...@free.fr added the comment:
After further testing, it turns out that Windows exhibits BSD-like behaviour
too. So instead of complicating the flag-setting code again, I suggest an
alternative of doing it in the Python wrapper. Patch attached.
--
Added file:
Martin v. Löwis mar...@v.loewis.de added the comment:
I like the logic of Antoine's patch much better (basing this on whether the
listening socket had a timeout). I wonder whether it's correct though if there
is a defaulttimeout: shouldn't it then leave the timeout on the socket instead?
Ross Lagerwall rosslagerw...@gmail.com added the comment:
issue1515839 seems to be a duplicate of this one.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7995
___
Antoine Pitrou pit...@free.fr added the comment:
Thanks for the patch. Comments/questions:
- please don't use C++-style comments (//) in C code; some compilers can
choke on them
- should the code path be also enabled for netbsd? (or other variants?)
- why does the test silence socket.error on
Ross Lagerwall rosslagerw...@gmail.com added the comment:
From what I coud see, the same applied to NetBSD so I enabled it for NetBSD as
well - if there are any other OSes that need it enabled, they can be added.
The updated patch checks for fcntl() failing and simply leaves the socket as is
Ross Lagerwall rosslagerw...@gmail.com added the comment:
Attached is a patch (the original one in patch form) against py3k with unit
test.
It seems to work well - tested on Linux FreeBSD.
--
keywords: +patch
nosy: +rosslagerwall
Added file:
Antoine Pitrou pit...@free.fr added the comment:
Well, unless someone explains convincingly how the current behaviour is
desireable (rather than misleading and useless), I really think this is
a bug that should be fix (then we can also discuss what the fix should
exactly be).
So
Ned Deily n...@acm.org added the comment:
(See also Issue7322)
--
nosy: +ned.deily
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7995
___
___
Roy Smith r...@panix.com added the comment:
The answer depends on what the socket module is trying to do. Is the goal
simply to provide a pythonic thin wrapper over the underlying OS interfaces
without altering their semantics, or to provide a completely homogeneous
abstraction? Having
Changes by Antoine Pitrou pit...@free.fr:
--
nosy: +exarkun
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7995
___
___
Python-bugs-list mailing
Antoine Pitrou pit...@free.fr added the comment:
Oh, and a test should be added of course.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7995
___
Antoine Pitrou pit...@free.fr added the comment:
It seems to me that it's a reasonable request. There is indeed a bug, since
Python uses non-blocking sockets to implement its timeout feature, and flags
inheritance means Python's view of whether the socket is non-blocking is not in
sync with
Martin v. Löwis mar...@v.loewis.de added the comment:
The answer depends on what the socket module is trying to do. Is the
goal simply to provide a pythonic thin wrapper over the underlying OS
interfaces without altering their semantics, or to provide a
completely homogeneous abstraction?
Justin Cappos justincap...@gmail.com added the comment:
Apparently, the designers of BSD thought differently. Remember that
it is them who defined the socket API in the first place, so they
have the right that their design decisions are considered.
I think there is a bit of confusion here.
Antoine Pitrou pit...@free.fr added the comment:
Anyway, my personal opinion is that we should consider the current
behavior a bug and fix it. I like the idea of setting all accepted
sockets to blocking mode (and documenting it clearly).
-1.
I think it is what most people would
Martin v. Löwis mar...@v.loewis.de added the comment:
Here is the issue (put plainly):
Unfortunately, I still don't understand it. I go through your plain
elaboration below.
Python sockets support a notion of timeout (note this notion is not
reflected in the OS socket API).
Correct.
The
Martin v. Löwis mar...@v.loewis.de added the comment:
We are talking about the timeout feature, which is a Python feature, not
a BSD (or Linux) sockets feature. It should work properly, even if that
means adding some boilerplate around system calls.
I agree that the semantics of the socket
Antoine Pitrou pit...@free.fr added the comment:
Le dimanche 21 novembre 2010 à 20:16 +, Martin v. Löwis a écrit :
We are talking about the timeout feature, which is a Python feature, not
a BSD (or Linux) sockets feature. It should work properly, even if that
means adding some
Justin Cappos justincap...@gmail.com added the comment:
This implementation assumes that the OS sets any socket it receives
via accept to nonblocking. (this is a false assumption on BSD)
Not true. It doesn't assume that (it doesn't assume the reverse,
either).
The Python implementation
Martin v. Löwis mar...@v.loewis.de added the comment:
Well, I don't think setting a timeout on a listening socket and then
expecting the socket received through accept() to be non-blocking (but
only on BSD) is a legitimate application.
Right. But setting the server socket to nonblocking, and
Justin Cappos justincap...@gmail.com added the comment:
Well, I don't think setting a timeout on a listening socket and then
expecting the socket received through accept() to be non-blocking (but
only on BSD) is a legitimate application.
Right. But setting the server socket to
Martin v. Löwis mar...@v.loewis.de added the comment:
The Python implementation sets timeout=None (which implies that the
underlying socket is blocking).
No, it doesn't. A socket may be non-blocking without having a timeout;
that's the socket API (on all systems, not just BSD).
The problem
Martin v. Löwis mar...@v.loewis.de added the comment:
However, I hope we can all agree that having the Python socket object
in a different blocking / non-blocking state than the OS socket
descriptor is wrong. This is what needs to be fixed.
Ok, now I see where your misunderstanding is: you
Roy Smith r...@panix.com added the comment:
I got into this by starting with Issue7322, which reports a scenario where data
is lost using makefile(). The docs for makefile() say, The socket must be in
blocking mode (it can not have a timeout). So, we've got published
documentation which
Martin v. Löwis mar...@v.loewis.de added the comment:
I got into this by starting with Issue7322, which reports a scenario
where data is lost using makefile(). The docs for makefile() say,
The socket must be in blocking mode (it can not have a timeout).
So, we've got published documentation
Ned Deily n...@acm.org added the comment:
The notes in the documentation under socket.gettimeout() do go into more detail
than elsewhere. But at least one thing there is at best misleading: Sockets
are always created in blocking mode is, as we've seen, not correct for BSD-ish
systems for
Roy Smith r...@panix.com added the comment:
Responding to msg122013:
I think he exactly meant to equate the two.
The original problem described in issue882297 is that the makefile()
documentation only stated that the socket could not be in non-blocking mode.
The test case presented didn't
Antoine Pitrou pit...@free.fr added the comment:
The notes in the documentation under socket.gettimeout() do go into
more detail than elsewhere. But at least one thing there is at best
misleading: Sockets are always created in blocking mode is, as we've
seen, not correct for BSD-ish systems
Justin Cappos justincap...@gmail.com added the comment:
The Python implementation sets timeout=None (which implies that the
underlying socket is blocking).
No, it doesn't. A socket may be non-blocking without having a timeout;
that's the socket API (on all systems, not just BSD).
Sure and
Martin v. Löwis mar...@v.loewis.de added the comment:
Well, unless someone explains convincingly how the current behaviour is
desireable (rather than misleading and useless), I really think this is
a bug that should be fix (then we can also discuss what the fix should
exactly be).
So please
Martin v. Löwis mar...@v.loewis.de added the comment:
Set blocking or non-blocking mode of the socket: if flag is 0, the
socket is set to non-blocking, else to blocking mode.
This seems to imply that timeout = None - blocking.
I see. So gettimeout() should really make a system call, to
Ronald Oussoren ronaldousso...@mac.com added the comment:
I've removed 2.5 and added 3.2 because there won't be further bugfix releases
of 2.5 and the issue also affects 3.2.
IMHO changing this behavior is not a bugfix and is therefore out of scope for
2.6.x, in particular because this change
New submission from Justin Cappos justincap...@gmail.com:
Suppose there is a program that has a listening socket that calls accept to
obtain new sockets for client connections. socketmodule.c assumes that these
client sockets have timeouts / blocking in the default state for new sockets
53 matches
Mail list logo
