Christophe Devriese <christophe.devri...@gmail.com> added the comment:
I realize this bugreport cannot fix 35 years of a bad design decision in
linux. That's not the intention (that's a gordian knot I *will* be keeping a
safe distance from). The intention is to create a saner default situation
for most python programs.
Christophe
2011/5/20 Charles-François Natali <rep...@bugs.python.org>
>
> Charles-François Natali <neolo...@free.fr> added the comment:
>
> Hello Christophe,
>
> First and foremost, I think that the FD_CLOEXEC approach is terminally
> broken, as it should have been the default in Unix. Now, we're stuck with
> this bad design.
> But we can't simply change the default to FD_CLOEXEC, for two reasons:
> - we can't silently change the Unix semantics
> - this is going to break some applications: for example, FD inherited
> across exec is used by super servers such as inetd, and there are others
> very legitimate uses
>
> > in the class TCPServer
> > add the following 2 lines in __init__ after self.socket = socket( ...:
> > flags = fcntl.fcntl(self.socket, fcntl.F_GETFD)
> > fcntl.fcntl(self.socket, fcntl.F_SETFD, flags | fcntl.FD_CLOEXEC)
>
> There are at least two problems with this approach:
> 1) there's a race between the socket creation and the call to fcntl
> 2) accept doesn't necessarily inherit the FD_CLOEXEC flag
>
> 1) can be fixed on systems that support it through SOCK_CLOEXEC
> 2) can be fixed on systems that support it through accept4(), but it seems
> to break badly on some systems, see issue #10115
>
> But I think this is a perfectly legitimate request, so one approach to
> tackle this problem could be:
> - since accept4() seems to fail so badly in some configurations, the only
> portable and reliable choice left is probably to call accept() then
> fcntl(FD_CLOEXEC) (there's a race, but it's better than nothing). We might
> reconsider this syscall in a couple years when we're sure it's implemented
> correctly
> - in the socketserver module, add a new set_socket_cloexec attribute to
> BaseServer, which would do the right thing (i.e. create the socket with
> SOCK_CLOEXEC if available, otherwise call fcntl(FD_CLOEXEC)), and in
> TCPServer, call fcntl(FD_CLOEXEC) after accept.
>
> That way, this would at least fix the problem for people using the
> socketserver module. People using sockets directly of course have the option
> of using SOCK_CLOEXEC and fcntl(FD_CLOEXEC) explicitely in their code.
>
> Gregory, any thoughts on this?
>
> ----------
>
> _______________________________________
> Python tracker <rep...@bugs.python.org>
> <http://bugs.python.org/issue12107>
> _______________________________________
>
----------
Added file: http://bugs.python.org/file22038/unnamed
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue12107>
_______________________________________
I realize this bugreport cannot fix 35 years of a bad design decision in linux.
That's not the intention (that's a gordian knot I *will* be keeping a
safe distance from). The intention is to create a saner default situation for
most python programs.<div>
<br></div><div>Christophe<br><br><div class="gmail_quote">2011/5/20
Charles-François Natali <span dir="ltr"><<a
href="mailto:rep...@bugs.python.org";>rep...@bugs.python.org</a>></span><br><blockquote
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc
solid;padding-left:1ex;">
<br>
Charles-François Natali <<a
href="mailto:neolo...@free.fr";>neolo...@free.fr</a>> added the comment:<br>
<br>
Hello Christophe,<br>
<br>
First and foremost, I think that the FD_CLOEXEC approach is terminally broken,
as it should have been the default in Unix. Now, we're stuck with this bad
design.<br>
But we can't simply change the default to FD_CLOEXEC, for two reasons:<br>
- we can't silently change the Unix semantics<br>
- this is going to break some applications: for example, FD inherited across
exec is used by super servers such as inetd, and there are others very
legitimate uses<br>
<div class="im"><br>
> Â in the class TCPServer<br>
> Â add the following 2 lines in __init__ after self.socket = socket(
...:<br>
> Â Â flags = fcntl.fcntl(self.socket, fcntl.F_GETFD)<br>
> Â Â fcntl.fcntl(self.socket, fcntl.F_SETFD, flags | fcntl.FD_CLOEXEC)<br>
<br>
</div>There are at least two problems with this approach:<br>
1) there's a race between the socket creation and the call to fcntl<br>
2) accept doesn't necessarily inherit the FD_CLOEXEC flag<br>
<br>
1) can be fixed on systems that support it through SOCK_CLOEXEC<br>
2) can be fixed on systems that support it through accept4(), but it seems to
break badly on some systems, see issue #10115<br>
<br>
But I think this is a perfectly legitimate request, so one approach to tackle
this problem could be:<br>
- since accept4() seems to fail so badly in some configurations, the only
portable and reliable choice left is probably to call accept() then
fcntl(FD_CLOEXEC) (there's a race, but it's better than nothing). We
might reconsider this syscall in a couple years when we're sure it's
implemented correctly<br>
- in the socketserver module, add a new set_socket_cloexec attribute to
BaseServer, which would do the right thing (i.e. create the socket with
SOCK_CLOEXEC if available, otherwise call fcntl(FD_CLOEXEC)), and in TCPServer,
call fcntl(FD_CLOEXEC) after accept.<br>
<br>
That way, this would at least fix the problem for people using the socketserver
module. People using sockets directly of course have the option of using
SOCK_CLOEXEC and fcntl(FD_CLOEXEC) explicitely in their code.<br>
<br>
Gregory, any thoughts on this?<br>
<br>
----------<br>
<div><div></div><div class="h5"><br>
_______________________________________<br>
Python tracker <<a
href="mailto:rep...@bugs.python.org";>rep...@bugs.python.org</a>><br>
<<a href="http://bugs.python.org/issue12107";
target="_blank">http://bugs.python.org/issue12107</a>><br>
_______________________________________<br>
</div></div></blockquote></div><br></div>
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
