[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20080424162444.1c5b9ba2@the-village.bc.nu>
Date: Thu, 24 Apr 2008 16:24:44 +0100
From: Alan Cox <alan@...rguk.ukuu.org.uk>
To: Jakub Jelinek <jakub@...hat.com>
Cc: Ulrich Drepper <drepper@...hat.com>, linux-kernel@...r.kernel.org,
netdev@...r.kernel.org, akpm@...ux-foundation.org,
torvalds@...ux-foundation.org
Subject: Re: [PATCH] alternative to sys_indirect, part 1
> Doing:
>
> int fd = socket (PF_INET, SOCK_STREAM, 0);
> fcntl (fd, F_SETFD, F_CLOEXEC);
> ...
> int fd2 = accept (fd, addr, addrlen);
>
> certainly doesn't use any of the new interfaces, yet if accept inherits
> the CLOEXEC flag from the socket, would visibly change existing programs.
The example you give doesn't involve the new interfaces so is outside of
the proposed changes but it is true that a different accept behaviour
would be odd here. Also accept() has several really really irritatingly
undefined semantics already that cause BSD v Linux pain and suffering so
maybe accept() is one case that could benefit from a flag passing version
*and* the ability to pass FNDELAY to accept to do non blocking accepts on
an fd without flipping it to/from NDELAY itself.
BTW in 4.4BSD and derivatives if I remember rightly F_CLOEXEC *is*
inherited across accept() so I doubt any user space software will be too
upset by such a shift.
Alan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists