Christophe Devriese 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
>
> Charles-François Natali 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
> <http://bugs.python.org/issue12107>
> ___
>
--
Added file: http://bugs.python.org/file22038/unnamed
___
Python tracker
<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.
Christophe2011/5/20
Charles-François Natali <mailto:[email protected]";>[email protected]>
Charles-François Natali <mailto:[email protected]";>[email protected]> 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 w
