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
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
"
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_DONTW
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 descri
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
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)
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 thi
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
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
9 matches
Mail list logo
