Vetoshkin Nikita nikita.vetosh...@gmail.com added the comment:
Started implementing accept4() socket method and stuck on socket object's
timeout attribute. What value should we assign to sock-sock_timeout if
SOCK_NONBLOCK was specified in accept4() call? And in socket.py should we check
as in
Vetoshkin Nikita nikita.vetosh...@gmail.com added the comment:
Sorry, wrong ticket. Right one is 10115
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7523
___
Antoine Pitrou pit...@free.fr added the comment:
Patch committed in r85480, thanks!
--
resolution: - fixed
stage: needs patch - committed/rejected
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7523
Changes by Giampaolo Rodola' g.rod...@gmail.com:
--
nosy: +giampaolo.rodola
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7523
___
___
Vetoshkin Nikita nikita.vetosh...@gmail.com added the comment:
Another patch with:
- testInitBlocking method
- no c++ style comments
- a newly generated configure script (almost 1.5k lines diff)
- proper accept4 availability check
With this patch I've got
Traceback (most recent call last):
Vetoshkin Nikita nikita.vetosh...@gmail.com added the comment:
Here's what strace on FAIL shows (print in alarm_handler added)
alarm(2)= 0
poll([{fd=3, events=POLLIN}], 1, 5000) = ? ERESTART_RESTARTBLOCK (To be
restarted)
--- SIGALRM (Alarm clock) @ 0 (0) ---
Antoine Pitrou pit...@free.fr added the comment:
For some reason does another trip through BEGIN_SELECT_LOOP() macro
Indeed:
if (!timeout)
+#ifdef HAVE_ACCEPT4
+/* inherit socket flags and use accept4 call */
+flags = s-sock_type (SOCK_CLOEXEC | SOCK_NONBLOCK);
+
Vetoshkin Nikita nikita.vetosh...@gmail.com added the comment:
@Antoine already found that myself, patched and tested :) thanks!
--
Added file: http://bugs.python.org/file19226/issue7523_py3k_accept4_2.diff
___
Python tracker rep...@bugs.python.org
Vetoshkin Nikita nikita.vetosh...@gmail.com added the comment:
Made an attempt to port lekma's patch to py3k-trunk. No (logical) changes
needed.
Don't know about accept4() issue. As I saw in Qt sources, they ifdef'ed CLOEXEC
by default on file descriptors. Don't think it's acceptable :) in
Antoine Pitrou pit...@free.fr added the comment:
The accept() issue is the following: the socket created by accept() (in
Lib/socket.py) will formally inherit its parent's `type` attribute (including
any SOCK_NONBLOCK and SOCK_CLOEXEC flags).
However, the underlying Linux socket is created by
Vetoshkin Nikita nikita.vetosh...@gmail.com added the comment:
Thanks! I can see the problem now, but I think checking should be done like
this:
fcntl.fcntl(c, fcntl.F_GETFD) fcntl.FD_CLOEXEC
0
fcntl.fcntl(s, fcntl.F_GETFD) fcntl.FD_CLOEXEC
1
and with accept4() call I've got flag set:
Antoine Pitrou pit...@free.fr added the comment:
You can check accept4() presence by adding it to the AC_CHECK_FUNCS macro in
configure.in around line 2553, and add the corresponding HAVE_ACCEPT4 lines in
pyconfig.h.in. Then run autoconf and you will have access to a HAVE_ACCEPT4
constant
Mark Lawrence breamore...@yahoo.co.uk added the comment:
@Antoine could you respond to msg97699, thanks.
--
nosy: +BreamoreBoy
versions: -Python 2.7
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7523
Antoine Pitrou pit...@free.fr added the comment:
@Antoine could you respond to msg97699, thanks.
Well my comments and the patch itself are outdated now that 2.7 is in bugfix
mode. The socket implementation in 3.2 is slightly different, which means the
patch should be updated (it isn't
lekma lekma...@gmail.com added the comment:
lekma, do you have a real name that we should add to the ACKS file?
no, lekma is fine (that's a nick I carry since childhood)
Looking at it again, there's the question of accept() behaviour. [...]
Sorry for not having seen that earlier and thanks
Antoine Pitrou pit...@free.fr added the comment:
The patch is basically fine. I'll add a try .. finally to the tests.
lekma, do you have a real name that we should add to the ACKS file?
--
___
Python tracker rep...@bugs.python.org
Antoine Pitrou pit...@free.fr added the comment:
Looking at it again, there's the question of accept() behaviour. In the
original code, it will call internal_setblocking() on the new fd if the
listening socket is non-blocking. In the new code, if SOCK_NONBLOCK is defined
it will not call any
lekma lekma...@gmail.com added the comment:
this one addresses Antoines's comments (with the help of R. David Murray).
--
Added file: http://bugs.python.org/file15621/Issue7523_3.diff
___
Python tracker rep...@bugs.python.org
lekma lekma...@gmail.com added the comment:
It would be better to use test skipping: (eg: @unittest.SkipUnless
before the test class).
I didn't know about this feature, thanks for the tip.
Now I wonder if it would be better to do it this way:
@unittest.SkipUnless(hasattr(socket,
R. David Murray rdmur...@bitdance.com added the comment:
I lean toward the second way, myself.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7523
___
R. David Murray rdmur...@bitdance.com added the comment:
It would be better to use test skipping: (eg: @unittest.SkipUnless
before the test class).
--
nosy: +r.david.murray
priority: - normal
stage: - patch review
___
Python tracker
Antoine Pitrou pit...@free.fr added the comment:
A couple of things:
- the test shouldn't be marked as Linux-specific since perhaps these
constants will be supported by other systems some day
- when importing fcntl, bear in mind that some systems don't have this
module (e.g. Windows), so you
lekma lekma...@gmail.com added the comment:
- when importing fcntl, bear in mind that some systems don't have this
module (e.g. Windows), so you should catch and silence the ImportError
would something like the following be ok?:
try:
import fcntl
except ImportError:
fcntl = False
New submission from lekma lekma...@gmail.com:
It would be nice to have those.
See http://udrepper.livejournal.com/20407.html for background.
--
components: Library (Lib)
messages: 96482
nosy: lekma
severity: normal
status: open
title: add SOCK_NONBLOCK and SOCK_CLOEXEC to socket module
lekma lekma...@gmail.com added the comment:
First attempt, against trunk.
--
keywords: +patch
Added file: http://bugs.python.org/file15573/Issue7523.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7523
lekma lekma...@gmail.com added the comment:
better patch (mainly test refactoring).
still against trunk.
should I provide one against py3k?
--
components: +IO
Added file: http://bugs.python.org/file15578/Issue7523_2.diff
___
Python tracker
26 matches
Mail list logo
