Re: F_DUPFD_CLOEXEC implementation

2007-10-02 Thread Davide Libenzi
On Tue, 2 Oct 2007, Denys Vlasenko wrote: > I have following proposals: > > * make recv(..., MSG_DONTWAIT) work on any fd > > Sounds neat, but not trivial to implement in current kernel. This is mildly ugly, if you ask me. Those are socket functions, and the flags parameter contain some pretty

Re: F_DUPFD_CLOEXEC implementation

2007-10-02 Thread Denys Vlasenko
On Monday 01 October 2007 20:04, Davide Libenzi wrote: > > They don't even need to read in parallel, just having shared fd is enough. > > Think about pipes, sockets and terminals. A real-world scenario: > > > > * a process started from shell (interactive or shell script) > > * it sets O_NONBLOCK a

Re: F_DUPFD_CLOEXEC implementation

2007-10-01 Thread Davide Libenzi
On Mon, 1 Oct 2007, Denys Vlasenko wrote: > On Monday 01 October 2007 19:16, Al Viro wrote: > > * it's on a bunch of cyclic lists. Have its neighbor > > go away while you are doing all that crap => boom > > * there's that thing call current position... It gets buggered. > > * overwri

Re: F_DUPFD_CLOEXEC implementation

2007-10-01 Thread Michael Tokarev
Al Viro wrote: > On Mon, Oct 01, 2007 at 11:07:15AM +0100, Denys Vlasenko wrote: >> Also attached is ndelaytest.c which can be used to test that >> send(MSG_DONTWAIT) indeed is failing with EAGAIN if write would block >> and that other processes never see O_NONBLOCK set. >> >> Comments? > > Never

Re: F_DUPFD_CLOEXEC implementation

2007-10-01 Thread Denys Vlasenko
On Monday 01 October 2007 19:16, Al Viro wrote: > * it's on a bunch of cyclic lists. Have its neighbor > go away while you are doing all that crap => boom > * there's that thing call current position... It gets buggered. > * overwriting it while another task might be in the midd

Re: F_DUPFD_CLOEXEC implementation

2007-10-01 Thread Al Viro
On Mon, Oct 01, 2007 at 11:07:15AM +0100, Denys Vlasenko wrote: > Also attached is ndelaytest.c which can be used to test that > send(MSG_DONTWAIT) indeed is failing with EAGAIN if write would block > and that other processes never see O_NONBLOCK set. > > Comments? Never send patches during or ap

Re: F_DUPFD_CLOEXEC implementation

2007-10-01 Thread Denys Vlasenko
On Monday 01 October 2007 04:15, Davide Libenzi wrote: > On Mon, 1 Oct 2007, Denys Vlasenko wrote: > > > My use case is: I want to do a nonblocking read on descriptor 0 (stdin). > > It may be a pipe or a socket. > > > > There may be other processes which share this descriptor with me, > > I simpl

Re: F_DUPFD_CLOEXEC implementation

2007-09-30 Thread Davide Libenzi
On Mon, 1 Oct 2007, Denys Vlasenko wrote: > My use case is: I want to do a nonblocking read on descriptor 0 (stdin). > It may be a pipe or a socket. > > There may be other processes which share this descriptor with me, > I simply cannot know that. And they, too, may want to do reads on it. > > I

Re: F_DUPFD_CLOEXEC implementation

2007-09-30 Thread Miquel van Smoorenburg
In article <[EMAIL PROTECTED]>, Denys Vlasenko <[EMAIL PROTECTED]> wrote: >Hi Ulrich, > >On Friday 28 September 2007 18:34, Ulrich Drepper wrote: >> One more small change to extend the availability of creation of >> file descriptors with FD_CLOEXEC set. Adding a new command to >> fcntl() requires

Re: F_DUPFD_CLOEXEC implementation

2007-09-30 Thread Denys Vlasenko
On Monday 01 October 2007 00:11, Davide Libenzi wrote: > On Sun, 30 Sep 2007, Denys Vlasenko wrote: > > > Hi Ulrich, > > > > On Friday 28 September 2007 18:34, Ulrich Drepper wrote: > > > One more small change to extend the availability of creation of > > > file descriptors with FD_CLOEXEC set.

Re: F_DUPFD_CLOEXEC implementation

2007-09-30 Thread Davide Libenzi
On Sun, 30 Sep 2007, Denys Vlasenko wrote: > Hi Ulrich, > > On Friday 28 September 2007 18:34, Ulrich Drepper wrote: > > One more small change to extend the availability of creation of > > file descriptors with FD_CLOEXEC set. Adding a new command to > > fcntl() requires no new system call and t

Re: F_DUPFD_CLOEXEC implementation

2007-09-29 Thread Denys Vlasenko
Hi Ulrich, On Friday 28 September 2007 18:34, Ulrich Drepper wrote: > One more small change to extend the availability of creation of > file descriptors with FD_CLOEXEC set. Adding a new command to > fcntl() requires no new system call and the overall impact on > code size if minimal. Tangential

Re: F_DUPFD_CLOEXEC implementation

2007-09-28 Thread Ulrich Drepper
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Davide Libenzi wrote: > I think new system calls would have been a cleaner way to accomplish this. > The "small pill at a time" may have better chance to go in, but will > likely result in an uglier userspace interface. We'd need this call anyway si

Re: F_DUPFD_CLOEXEC implementation

2007-09-28 Thread Davide Libenzi
On Fri, 28 Sep 2007, Ulrich Drepper wrote: > One more small change to extend the availability of creation of > file descriptors with FD_CLOEXEC set. Adding a new command to > fcntl() requires no new system call and the overall impact on > code size if minimal. > > If this patch gets accepted we