Re: No Bug: accept discards socket options/O_NONBLOCK
On Fri, 15 Sep 2000, Michael Poole wrote: > Most of the programs called by inetd don't expect non-blocking I/O on > their stdin and stdout, which they would suddenly get if accept()'ed > sockets inherited the non-blocking nature of inetd's listening socket. Looking at nkit 0.4.2, I cannot see a thing such as a non-blocking listening socket (name the line if there is). Where does inetd set its listening sockets to O_NONBLOCK? Why should an application that originates on BSD misbehave if it got BSD semantics? -- Matthias Andree - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: No Bug: accept discards socket options/O_NONBLOCK
On Fri, 15 Sep 2000, D. J. Bernstein wrote: > O_NONBLOCK is not an fd property. It is an ofile property. Two different > fds created by dup() will point to the same O_NONBLOCK bit. Who says that accept() is to use dup()? There is a difference in "new file descriptor" (what accept returns) and "copy of the file descriptor" (what dup returns). You are relying on unspecified implementation details(*) and claiming Linux was buggy. Please show papers that document either that accept must use dup or that accept must copy file descriptor flags before claiming someone else misbehaving. *) unspecified as per SUS v2, Linux, FreeBSD, OpenBSD, NetBSD, Solaris, HP-UX manual pages. -- Matthias Andree - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: No Bug: accept discards socket options/O_NONBLOCK
On Fri, 15 Sep 2000, D. J. Bernstein wrote: O_NONBLOCK is not an fd property. It is an ofile property. Two different fds created by dup() will point to the same O_NONBLOCK bit. Who says that accept() is to use dup()? There is a difference in "new file descriptor" (what accept returns) and "copy of the file descriptor" (what dup returns). You are relying on unspecified implementation details(*) and claiming Linux was buggy. Please show papers that document either that accept must use dup or that accept must copy file descriptor flags before claiming someone else misbehaving. *) unspecified as per SUS v2, Linux, FreeBSD, OpenBSD, NetBSD, Solaris, HP-UX manual pages. -- Matthias Andree - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: No Bug: accept discards socket options/O_NONBLOCK
On Fri, 15 Sep 2000, Michael Poole wrote: Most of the programs called by inetd don't expect non-blocking I/O on their stdin and stdout, which they would suddenly get if accept()'ed sockets inherited the non-blocking nature of inetd's listening socket. Looking at nkit 0.4.2, I cannot see a thing such as a non-blocking listening socket (name the line if there is). Where does inetd set its listening sockets to O_NONBLOCK? Why should an application that originates on BSD misbehave if it got BSD semantics? -- Matthias Andree - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: No Bug: accept discards socket options/O_NONBLOCK
On Fri, Sep 15, 2000 at 05:39:35PM -, D. J. Bernstein wrote: > The absence of a non-blocking fd property causes reliability problems, > as discussed in http://cr.yp.to/docs/unixapi.html. I'd really like to > have ndelay_read() and ndelay_write() syscalls. You already have. Just pass MSG_DONTWAIT to send*/recv* -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: No Bug: accept discards socket options/O_NONBLOCK
I'm going to work around this Linux bug in the next release of djbdns, just as I've worked around many other Linux bugs in the past. But the bug is going to continue to bite people. Matthias Andree writes: > Now, interpreting properties as "socket properties", and O_NONBLOCK > being a file descriptor property, O_NONBLOCK is not an fd property. It is an ofile property. Two different fds created by dup() will point to the same O_NONBLOCK bit. The absence of a non-blocking fd property causes reliability problems, as discussed in http://cr.yp.to/docs/unixapi.html. I'd really like to have ndelay_read() and ndelay_write() syscalls. ---Dan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: No Bug: accept discards socket options/O_NONBLOCK
On Fri, Sep 15, 2000 at 07:01:32AM -0700, David S. Miller wrote: > Every Linux inetd in the world would instantly stop working. Pointer to docs on why this is not considered a bug in inetd? Also, you already know how to upgrade a syscall without breaking backwards compatability. > The behavior is not changing, lets end this thread right now. I'm not trying to say the behavior must change -- I'm trying to find out why it won't. ["I don't see the need", is something that I'd accept. However, "it would break inetd" doesn't make sense.] -- Raul - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [2.4][2.2] Bug: accept discards socket options/O_NONBLOCK
Hello! > This has been this way forever, it is thus an API and it is not > changing. Changing it would break existing programs. End of story. 8) However, imagine, freebsd folks changed this in their release 2.x. Alexey - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: No Bug: accept discards socket options/O_NONBLOCK
Matthias Andree <[EMAIL PROTECTED]> writes: > On Fri, 15 Sep 2000, David S. Miller wrote: > > > Every Linux inetd in the world would instantly stop working. > > Why should it? inetd.c does not touch fd flags. No F_SETFL, no > O_NONBLOCK, no fcntl. Why should inetd fail with a changed accept(2) > semantics? Most of the programs called by inetd don't expect non-blocking I/O on their stdin and stdout, which they would suddenly get if accept()'ed sockets inherited the non-blocking nature of inetd's listening socket. Personally, I think that the common case is that the caller will want the same blocking attribute for an accept()'ed socket as on the listening socket it came from, and inetd is the only app I have seen offered as a counterexample. If it's just one app, it can easily be changed and marked as required for upgrades to kernels that have the same semantics as the BSDs. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: No Bug: accept discards socket options/O_NONBLOCK
On Fri, 15 Sep 2000, David S. Miller wrote: > Every Linux inetd in the world would instantly stop working. Why should it? inetd.c does not touch fd flags. No F_SETFL, no O_NONBLOCK, no fcntl. Why should inetd fail with a changed accept(2) semantics? -- Matthias Andree - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: No Bug: accept discards socket options/O_NONBLOCK
Date: Fri, 15 Sep 2000 15:57:32 +0200 From: Matthias Andree <[EMAIL PROTECTED]> However, this makes Linux incompatible with *BSD and Solaris, so I'm wondering what this "break existing programs" would be, portable programs would most likely not break by the API change. Every Linux inetd in the world would instantly stop working. The behavior is not changing, lets end this thread right now. Later, David S. Miller [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: No Bug: accept discards socket options/O_NONBLOCK
On Fri, 15 Sep 2000, David S. Miller wrote: [accept not inheriting O_NONBLOCK] > The socket(7) manpage is buggy, not the kernel. > > This has been this way forever, it is thus an API and it is not > changing. Changing it would break existing programs. End of story. I have been looking through the Single Unix Specification v7 and various accept(2) man pages (NetBSD 1.3, SunOS 4.1.3, SunOS 5.7) and all go like this: "creates a new socket with the same properties as s." "creates a new file descriptor." - no mention if that has the same O_ flags as the listening socket. So it seems that BSD and Solaris 7 happen to copy the fd options as well, and Linux happens to just create a new fd, and both are right. Now, interpreting properties as "socket properties", and O_NONBLOCK being a file descriptor property, it may be legal to not copy the fd flags. However, this makes Linux incompatible with *BSD and Solaris, so I'm wondering what this "break existing programs" would be, portable programs would most likely not break by the API change. Break portability, that's what it actually does, regardless of who is correct. *sigh* -- Matthias Andree - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [2.4][2.2] Bug: accept discards socket options/O_NONBLOCK
Date:Fri, 15 Sep 2000 15:01:25 +0200 From: Matthias Andree <[EMAIL PROTECTED]> BUG DESCRIPTION: (This is for IPv4, someone would have to check IPv6 as well). The socket flag O_NONBLOCK is _NOT_ properly inherited through an accept(2) call, in spite of what socket(7) documents. This is a bug. accept(2) must copy the file descriptor's flag of the socket. Yes, it's true that BSD apparently has this behaviour. The problem is that there are existing Linux programs that are fairly widely deployed that would break if we made this change now. And even if we did make the change, the existing deployed 2.2 kernels, which represents a huge installed base, would still be around for a long time. BSD'er's can kvetch about our not following "the BSD sockets interface". I'd be a lot more sympathetic if the CSRG had bothered to actually write it down as a formal specification, and if the CSRG themselves didn't make random, not-always-backwards-compatible changes to the interfaces from 4.3, 4.3Reno, 4.3Tahoe, and 4.4. Oh, well. My suggestion is to document that if you want a well-written, portable program, you must set the file descriptor flags after an accept(2) call. It's not ideal, but it's the best way to make sure your application program will run on the widest possible array of systems. No, this is not ideal. But it's life. - Ted - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [2.4][2.2] Bug: accept discards socket options/O_NONBLOCK
On Fri, 15 Sep 2000, Matthias Andree wrote: > BUG DESCRIPTION: > (This is for IPv4, someone would have to check IPv6 as well). > The socket flag O_NONBLOCK is _NOT_ properly inherited through an > accept(2) call, in spite of what socket(7) documents. This is a bug. > accept(2) must copy the file descriptor's flag of the socket. No-one has yet located a standards document which mandates this behaviour, AFAIK. Unless such a document is found, the bug lies in dnscache for assuming something it is not entitled to assume. Cheers Chris - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [2.4][2.2] Bug: accept discards socket options/O_NONBLOCK
On Fri, Sep 15, 2000 at 05:54:14AM -0700, David S. Miller wrote: >Date: Fri, 15 Sep 2000 15:01:25 +0200 >From: Matthias Andree <[EMAIL PROTECTED]> > > (This is for IPv4, someone would have to check IPv6 as well). > The socket flag O_NONBLOCK is _NOT_ properly inherited through an > accept(2) call, in spite of what socket(7) documents. This is a bug. > accept(2) must copy the file descriptor's flag of the socket. > > The socket(7) manpage is buggy, not the kernel. Fixed on vger now. I planned to send an update to Andries soon anyways. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [2.4][2.2] Bug: accept discards socket options/O_NONBLOCK
Date: Fri, 15 Sep 2000 15:01:25 +0200 From: Matthias Andree <[EMAIL PROTECTED]> (This is for IPv4, someone would have to check IPv6 as well). The socket flag O_NONBLOCK is _NOT_ properly inherited through an accept(2) call, in spite of what socket(7) documents. This is a bug. accept(2) must copy the file descriptor's flag of the socket. The socket(7) manpage is buggy, not the kernel. This has been this way forever, it is thus an API and it is not changing. Changing it would break existing programs. End of story. Later, David S. Miller [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[2.4][2.2] Bug: accept discards socket options/O_NONBLOCK
Please mind the To: and Cc: headers. If there are relevant followups, please send me a Cc: as I'm only subscribed to the linux-kernel and dns mailing lists. In some debugging, Pavel Kankovsky and Daniel J. Bernstein have tracked down a Linux Kernel bug that I can confirm for 2.2.17 and 2.4.0-test8 (I did not try 2.0.38, don't have gcc 2.7.2.3 installed). I have copies of their mail (without Received: headers) available (see below). BUG DESCRIPTION: (This is for IPv4, someone would have to check IPv6 as well). The socket flag O_NONBLOCK is _NOT_ properly inherited through an accept(2) call, in spite of what socket(7) documents. This is a bug. accept(2) must copy the file descriptor's flag of the socket. SOCKET(7) EXCERPT: (from man pages 1.31) It is possible to do non-blocking IO on sockets by setting the O_NONBLOCK flag on a socket file descriptor using fcntl(2). O_NONBLOCK is inherited through an accept. Then all operations that would normally block will (usu ally) return with EAGAIN; connect(2) returns an EIN PROGRESS error in this case. The user can then wait for various events via poll(2) or select(2). EXAMPLE: At http://home.pages.de/~mandree/socktest.c, there is a small test program (3 kB) that is not really portable, and that relies on dnscache for library functions (it's a quick hack). Build it on Linux 2.2 or Linux 2.4.0-test8 and see this: (I'm running ./socktest 1234 & telnet localhost 1234) options on socket (fd=3): O_NONBLOCK options after accept (fd=6): accepted from 127.0.0.1:1068 It SHOULD be: (FreeBSD 4.0 gets it right): options on socket (fd=3): O_NONBLOCK options after accept (fd=4): O_NONBLOCK accepted from 127.0.0.1:1053 To compile the program on FreeBSD 4, comment out the line with O_SYNC and insert #include ; compilation instructions are at the head of that file. REFERENCES: test program is at http://home.pages.de/~mandree/socktest.c dnscache source code is at http://cr.yp.to/djbdns/dnscache-1.00.tar.gz (78 kB). Pavel's mail is at http://home.pages.de/~mandree/2904102753.2572.0%40argo.troja.mff.cuni.cz Dan's mail is at http://home.pages.de/~mandree/2904193940.20671.qmail%40cr.yp.to -- Matthias Andree - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: No Bug: accept discards socket options/O_NONBLOCK
Matthias Andree [EMAIL PROTECTED] writes: On Fri, 15 Sep 2000, David S. Miller wrote: Every Linux inetd in the world would instantly stop working. Why should it? inetd.c does not touch fd flags. No F_SETFL, no O_NONBLOCK, no fcntl. Why should inetd fail with a changed accept(2) semantics? Most of the programs called by inetd don't expect non-blocking I/O on their stdin and stdout, which they would suddenly get if accept()'ed sockets inherited the non-blocking nature of inetd's listening socket. Personally, I think that the common case is that the caller will want the same blocking attribute for an accept()'ed socket as on the listening socket it came from, and inetd is the only app I have seen offered as a counterexample. If it's just one app, it can easily be changed and marked as required for upgrades to kernels that have the same semantics as the BSDs. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: No Bug: accept discards socket options/O_NONBLOCK
I'm going to work around this Linux bug in the next release of djbdns, just as I've worked around many other Linux bugs in the past. But the bug is going to continue to bite people. Matthias Andree writes: Now, interpreting properties as "socket properties", and O_NONBLOCK being a file descriptor property, O_NONBLOCK is not an fd property. It is an ofile property. Two different fds created by dup() will point to the same O_NONBLOCK bit. The absence of a non-blocking fd property causes reliability problems, as discussed in http://cr.yp.to/docs/unixapi.html. I'd really like to have ndelay_read() and ndelay_write() syscalls. ---Dan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: No Bug: accept discards socket options/O_NONBLOCK
On Fri, Sep 15, 2000 at 05:39:35PM -, D. J. Bernstein wrote: The absence of a non-blocking fd property causes reliability problems, as discussed in http://cr.yp.to/docs/unixapi.html. I'd really like to have ndelay_read() and ndelay_write() syscalls. You already have. Just pass MSG_DONTWAIT to send*/recv* -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: No Bug: accept discards socket options/O_NONBLOCK
Date: Fri, 15 Sep 2000 15:57:32 +0200 From: Matthias Andree [EMAIL PROTECTED] However, this makes Linux incompatible with *BSD and Solaris, so I'm wondering what this "break existing programs" would be, portable programs would most likely not break by the API change. Every Linux inetd in the world would instantly stop working. The behavior is not changing, lets end this thread right now. Later, David S. Miller [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [2.4][2.2] Bug: accept discards socket options/O_NONBLOCK
Date: Fri, 15 Sep 2000 15:01:25 +0200 From: Matthias Andree [EMAIL PROTECTED] (This is for IPv4, someone would have to check IPv6 as well). The socket flag O_NONBLOCK is _NOT_ properly inherited through an accept(2) call, in spite of what socket(7) documents. This is a bug. accept(2) must copy the file descriptor's flag of the socket. The socket(7) manpage is buggy, not the kernel. This has been this way forever, it is thus an API and it is not changing. Changing it would break existing programs. End of story. Later, David S. Miller [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [2.4][2.2] Bug: accept discards socket options/O_NONBLOCK
Hello! This has been this way forever, it is thus an API and it is not changing. Changing it would break existing programs. End of story. 8) However, imagine, freebsd folks changed this in their release 2.x. Alexey - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: No Bug: accept discards socket options/O_NONBLOCK
On Fri, Sep 15, 2000 at 07:01:32AM -0700, David S. Miller wrote: Every Linux inetd in the world would instantly stop working. Pointer to docs on why this is not considered a bug in inetd? Also, you already know how to upgrade a syscall without breaking backwards compatability. The behavior is not changing, lets end this thread right now. I'm not trying to say the behavior must change -- I'm trying to find out why it won't. ["I don't see the need", is something that I'd accept. However, "it would break inetd" doesn't make sense.] -- Raul - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: No Bug: accept discards socket options/O_NONBLOCK
On Fri, 15 Sep 2000, David S. Miller wrote: Every Linux inetd in the world would instantly stop working. Why should it? inetd.c does not touch fd flags. No F_SETFL, no O_NONBLOCK, no fcntl. Why should inetd fail with a changed accept(2) semantics? -- Matthias Andree - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [2.4][2.2] Bug: accept discards socket options/O_NONBLOCK
On Fri, Sep 15, 2000 at 05:54:14AM -0700, David S. Miller wrote: Date: Fri, 15 Sep 2000 15:01:25 +0200 From: Matthias Andree [EMAIL PROTECTED] (This is for IPv4, someone would have to check IPv6 as well). The socket flag O_NONBLOCK is _NOT_ properly inherited through an accept(2) call, in spite of what socket(7) documents. This is a bug. accept(2) must copy the file descriptor's flag of the socket. The socket(7) manpage is buggy, not the kernel. Fixed on vger now. I planned to send an update to Andries soon anyways. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [2.4][2.2] Bug: accept discards socket options/O_NONBLOCK
On Fri, 15 Sep 2000, Matthias Andree wrote: BUG DESCRIPTION: (This is for IPv4, someone would have to check IPv6 as well). The socket flag O_NONBLOCK is _NOT_ properly inherited through an accept(2) call, in spite of what socket(7) documents. This is a bug. accept(2) must copy the file descriptor's flag of the socket. No-one has yet located a standards document which mandates this behaviour, AFAIK. Unless such a document is found, the bug lies in dnscache for assuming something it is not entitled to assume. Cheers Chris - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [2.4][2.2] Bug: accept discards socket options/O_NONBLOCK
Date:Fri, 15 Sep 2000 15:01:25 +0200 From: Matthias Andree [EMAIL PROTECTED] BUG DESCRIPTION: (This is for IPv4, someone would have to check IPv6 as well). The socket flag O_NONBLOCK is _NOT_ properly inherited through an accept(2) call, in spite of what socket(7) documents. This is a bug. accept(2) must copy the file descriptor's flag of the socket. Yes, it's true that BSD apparently has this behaviour. The problem is that there are existing Linux programs that are fairly widely deployed that would break if we made this change now. And even if we did make the change, the existing deployed 2.2 kernels, which represents a huge installed base, would still be around for a long time. BSD'er's can kvetch about our not following "the BSD sockets interface". I'd be a lot more sympathetic if the CSRG had bothered to actually write it down as a formal specification, and if the CSRG themselves didn't make random, not-always-backwards-compatible changes to the interfaces from 4.3, 4.3Reno, 4.3Tahoe, and 4.4. Oh, well. My suggestion is to document that if you want a well-written, portable program, you must set the file descriptor flags after an accept(2) call. It's not ideal, but it's the best way to make sure your application program will run on the widest possible array of systems. No, this is not ideal. But it's life. - Ted - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[2.4][2.2] Bug: accept discards socket options/O_NONBLOCK
Please mind the To: and Cc: headers. If there are relevant followups, please send me a Cc: as I'm only subscribed to the linux-kernel and dns mailing lists. In some debugging, Pavel Kankovsky and Daniel J. Bernstein have tracked down a Linux Kernel bug that I can confirm for 2.2.17 and 2.4.0-test8 (I did not try 2.0.38, don't have gcc 2.7.2.3 installed). I have copies of their mail (without Received: headers) available (see below). BUG DESCRIPTION: (This is for IPv4, someone would have to check IPv6 as well). The socket flag O_NONBLOCK is _NOT_ properly inherited through an accept(2) call, in spite of what socket(7) documents. This is a bug. accept(2) must copy the file descriptor's flag of the socket. SOCKET(7) EXCERPT: (from man pages 1.31) It is possible to do non-blocking IO on sockets by setting the O_NONBLOCK flag on a socket file descriptor using fcntl(2). O_NONBLOCK is inherited through an accept. Then all operations that would normally block will (usu ally) return with EAGAIN; connect(2) returns an EIN PROGRESS error in this case. The user can then wait for various events via poll(2) or select(2). EXAMPLE: At http://home.pages.de/~mandree/socktest.c, there is a small test program (3 kB) that is not really portable, and that relies on dnscache for library functions (it's a quick hack). Build it on Linux 2.2 or Linux 2.4.0-test8 and see this: (I'm running ./socktest 1234 telnet localhost 1234) options on socket (fd=3): O_NONBLOCK options after accept (fd=6): accepted from 127.0.0.1:1068 It SHOULD be: (FreeBSD 4.0 gets it right): options on socket (fd=3): O_NONBLOCK options after accept (fd=4): O_NONBLOCK accepted from 127.0.0.1:1053 To compile the program on FreeBSD 4, comment out the line with O_SYNC and insert #include poll.h; compilation instructions are at the head of that file. REFERENCES: test program is at http://home.pages.de/~mandree/socktest.c dnscache source code is at http://cr.yp.to/djbdns/dnscache-1.00.tar.gz (78 kB). Pavel's mail is at http://home.pages.de/~mandree/2904102753.2572.0%40argo.troja.mff.cuni.cz Dan's mail is at http://home.pages.de/~mandree/2904193940.20671.qmail%40cr.yp.to -- Matthias Andree - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: No Bug: accept discards socket options/O_NONBLOCK
On Fri, 15 Sep 2000, David S. Miller wrote: [accept not inheriting O_NONBLOCK] The socket(7) manpage is buggy, not the kernel. This has been this way forever, it is thus an API and it is not changing. Changing it would break existing programs. End of story. I have been looking through the Single Unix Specification v7 and various accept(2) man pages (NetBSD 1.3, SunOS 4.1.3, SunOS 5.7) and all go like this: "creates a new socket with the same properties as s." "creates a new file descriptor." - no mention if that has the same O_ flags as the listening socket. So it seems that BSD and Solaris 7 happen to copy the fd options as well, and Linux happens to just create a new fd, and both are right. Now, interpreting properties as "socket properties", and O_NONBLOCK being a file descriptor property, it may be legal to not copy the fd flags. However, this makes Linux incompatible with *BSD and Solaris, so I'm wondering what this "break existing programs" would be, portable programs would most likely not break by the API change. Break portability, that's what it actually does, regardless of who is correct. *sigh* -- Matthias Andree - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
