Re: bug in select() in linux
On Mon, 12 Mar 2007 16:02:11 +0100 "Lluís Batlle" <[EMAIL PROTECTED]> wrote: > Oh, of course you're right. I was inside too much layers to think of > the tcp protocol, and I did not pay attention to it. > > Maybe something could be added to the manpage anyway. > > The bad thing is that there's no way I can use a socket for writing > using select() if that connection has been half-closed by the other > end. Moo. You can because the only case it will block is when the transmit queue is partly or completely full which means that you will discover the connection has been reset when the transmit triggers a reset. If you wait on the FD concerned for write or exception events all should work nicely. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: bug in select() in linux
Wouldn't it be better for all of us that select() doesn't block on write(), unless there is a socket writting buffer fulfilled? It will be consistent with the select() specification. 2007/3/12, Alistair John Strachan <[EMAIL PROTECTED]>: On Monday 12 March 2007 15:02, Lluís Batlle wrote: > Oh, of course you're right. I was inside too much layers to think of > the tcp protocol, and I did not pay attention to it. > > Maybe something could be added to the manpage anyway. > > The bad thing is that there's no way I can use a socket for writing > using select() if that connection has been half-closed by the other > end. Moo. This question comes up from time to time. I think the answer is ultimately "select() sucks, use poll()". I can't exactly remember the details, but I believe POLLHUP or POLLOUT as flags do what you want. -- Cheers, Alistair. Final year Computer Science undergraduate. 1F2 55 South Clerk Street, Edinburgh, UK. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: bug in select() in linux
On Monday 12 March 2007 15:02, Lluís Batlle wrote: > Oh, of course you're right. I was inside too much layers to think of > the tcp protocol, and I did not pay attention to it. > > Maybe something could be added to the manpage anyway. > > The bad thing is that there's no way I can use a socket for writing > using select() if that connection has been half-closed by the other > end. Moo. This question comes up from time to time. I think the answer is ultimately "select() sucks, use poll()". I can't exactly remember the details, but I believe POLLHUP or POLLOUT as flags do what you want. -- Cheers, Alistair. Final year Computer Science undergraduate. 1F2 55 South Clerk Street, Edinburgh, UK. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: bug in select() in linux
Oh, of course you're right. I was inside too much layers to think of the tcp protocol, and I did not pay attention to it. Maybe something could be added to the manpage anyway. The bad thing is that there's no way I can use a socket for writing using select() if that connection has been half-closed by the other end. Moo. Thanks a lot for your time, Lluís 2007/3/12, Alan Cox <[EMAIL PROTECTED]>: > I've tried a select() for write against a closed tcp socket (closed by > the other side), and the select call _blocks_. A TCP close from the remote node is single sided. It sends a FIN and we ACK the FIN, that means only that the remote node has completed *sending*. > Any write() call to that socket will _not block_, and will return with EPIPE. We don't know this until you try the write. At that point the other end if it has closed entirely will issue an RST and terminate the connection in full. I don't therefore believe that this is actually a bug. Alan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
bug in select() in linux
Hello, I've found a problem in the select() call. The manpage states: "those in writefds will be watched to see if a write will not block" I've tried a select() for write against a closed tcp socket (closed by the other side), and the select call _blocks_. Any write() call to that socket will _not block_, and will return with EPIPE. I've seen this happening in 2.4.20 and 2.6.16.29 (xen patched) at least. Maybe it's a glibc problem - you may know better. Could you please keep me in carbon copy? I'm not sure I want to subscribe to LKML. Regards, Lluís. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
bug in select() in linux
Hello, I've found a problem in the select() call. The manpage states: those in writefds will be watched to see if a write will not block I've tried a select() for write against a closed tcp socket (closed by the other side), and the select call _blocks_. Any write() call to that socket will _not block_, and will return with EPIPE. I've seen this happening in 2.4.20 and 2.6.16.29 (xen patched) at least. Maybe it's a glibc problem - you may know better. Could you please keep me in carbon copy? I'm not sure I want to subscribe to LKML. Regards, Lluís. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: bug in select() in linux
Oh, of course you're right. I was inside too much layers to think of the tcp protocol, and I did not pay attention to it. Maybe something could be added to the manpage anyway. The bad thing is that there's no way I can use a socket for writing using select() if that connection has been half-closed by the other end. Moo. Thanks a lot for your time, Lluís 2007/3/12, Alan Cox [EMAIL PROTECTED]: I've tried a select() for write against a closed tcp socket (closed by the other side), and the select call _blocks_. A TCP close from the remote node is single sided. It sends a FIN and we ACK the FIN, that means only that the remote node has completed *sending*. Any write() call to that socket will _not block_, and will return with EPIPE. We don't know this until you try the write. At that point the other end if it has closed entirely will issue an RST and terminate the connection in full. I don't therefore believe that this is actually a bug. Alan - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: bug in select() in linux
On Monday 12 March 2007 15:02, Lluís Batlle wrote: Oh, of course you're right. I was inside too much layers to think of the tcp protocol, and I did not pay attention to it. Maybe something could be added to the manpage anyway. The bad thing is that there's no way I can use a socket for writing using select() if that connection has been half-closed by the other end. Moo. This question comes up from time to time. I think the answer is ultimately select() sucks, use poll(). I can't exactly remember the details, but I believe POLLHUP or POLLOUT as flags do what you want. -- Cheers, Alistair. Final year Computer Science undergraduate. 1F2 55 South Clerk Street, Edinburgh, UK. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: bug in select() in linux
Wouldn't it be better for all of us that select() doesn't block on write(), unless there is a socket writting buffer fulfilled? It will be consistent with the select() specification. 2007/3/12, Alistair John Strachan [EMAIL PROTECTED]: On Monday 12 March 2007 15:02, Lluís Batlle wrote: Oh, of course you're right. I was inside too much layers to think of the tcp protocol, and I did not pay attention to it. Maybe something could be added to the manpage anyway. The bad thing is that there's no way I can use a socket for writing using select() if that connection has been half-closed by the other end. Moo. This question comes up from time to time. I think the answer is ultimately select() sucks, use poll(). I can't exactly remember the details, but I believe POLLHUP or POLLOUT as flags do what you want. -- Cheers, Alistair. Final year Computer Science undergraduate. 1F2 55 South Clerk Street, Edinburgh, UK. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: bug in select() in linux
On Mon, 12 Mar 2007 16:02:11 +0100 Lluís Batlle [EMAIL PROTECTED] wrote: Oh, of course you're right. I was inside too much layers to think of the tcp protocol, and I did not pay attention to it. Maybe something could be added to the manpage anyway. The bad thing is that there's no way I can use a socket for writing using select() if that connection has been half-closed by the other end. Moo. You can because the only case it will block is when the transmit queue is partly or completely full which means that you will discover the connection has been reset when the transmit triggers a reset. If you wait on the FD concerned for write or exception events all should work nicely. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
