socket/select differences between glibc 2.1 and 2.2
Hi, Can anyone please explain the following behaviour. Consider the following: int main( int argc, char **argv ) { int s; fd_set dread; fd_set dwrite; struct timeval to; to.tv_sec = 3; to.tv_usec = 0; s = socket( AF_INET, SOCK_STREAM, 0 ); FD_ZERO(&dread); FD_ZERO(&dwrite); FD_SET(s, &dread); if (select(s + 1, &dread, &dwrite, (fd_set *) 0, &to) < 0) { fprintf(stderr, "Error in select(): errno=%d\n", errno); return errno; } return 0; } On a (Suse i386 linux) glibc-2.1.3-27 machine this blocks for the timeout of 3 seconds and the 'dread' fd_set is cleared and the select returns 0. On a (Suse i386 linux) glibc-2.2.2-67 machine this returns immediately and the 'dread' fd_set is left untouched and the select returns a value of 1. The program above is a toy that reproduces my problem, while calling select immediately on 's' may not be a meaningful thing to do, I just want to know what the correct semantics are and why they have changed. Cheers Andy ********************************************************************* * Andrew Cheadle email: a.cheadle@doc.ic.ac.uk * * Department of Computing http://www.doc.ic.ac.uk/~amc4/ * * Imperial College * * University of London * *********************************************************************
Having done my share of using select (mostly on commercial Unix systems), I think the only issue that I can see here is that your file descriptor is not really attached to a stream via one of the appropriate functions, such as listen() or connect(). I would think that the behavior is undefined. Why it would be different on the two libraries, I don't know. -- Jerry Feldman <gaf@blu.org> Boston Linux and Unix user group http://www.blu.org PGP key id:C5061EA9 PGP Key fingerprint:053C 73EC 3AC1 5C44 3E14 9245 FB00 3ED5 C506 1EA9 On Fri, 7 Feb 2003 18:54:18 +0000 (GMT) Andrew Cheadle <amc4@doc.ic.ac.uk> wrote:
Hi,
Can anyone please explain the following behaviour. Consider the following:
int main( int argc, char **argv ) { int s; fd_set dread; fd_set dwrite; struct timeval to;
to.tv_sec = 3; to.tv_usec = 0;
s = socket( AF_INET, SOCK_STREAM, 0 );
FD_ZERO(&dread); FD_ZERO(&dwrite); FD_SET(s, &dread);
if (select(s + 1, &dread, &dwrite, (fd_set *) 0, &to) < 0) { fprintf(stderr, "Error in select(): errno=%d\n", errno); return errno; }
return 0; }
On a (Suse i386 linux) glibc-2.1.3-27 machine this blocks for the timeout of 3 seconds and the 'dread' fd_set is cleared and the select returns 0.
On a (Suse i386 linux) glibc-2.2.2-67 machine this returns immediately and the 'dread' fd_set is left untouched and the select returns a value of 1.
The program above is a toy that reproduces my problem, while calling select immediately on 's' may not be a meaningful thing to do, I just want to know what the correct semantics are and why they have changed.
Cheers
Andy
********************************************************************* * Andrew Cheadle email: a.cheadle@doc.ic.ac.uk * * Department of Computing http://www.doc.ic.ac.uk/~amc4/ * * Imperial College * * University of London * *********************************************************************
-- To unsubscribe, email: suse-programming-e-unsubscribe@suse.com For additional commands, email: suse-programming-e-help@suse.com Archives can be found at: http://lists/archive/suse-programming-e
Hi Jerry, Thanks for your quick response. As I said, I know it's not a meaningful thing to necessarily do. And indeed I should have said the behaviour is correct once the stream is properly attached. I just happen to be working on a piece of legacy code that used the assumption that the select would block and I'm trying to determine if the assumption was ever valid ( you say not - you think behaviour should be undefined). So I guess my question is really: 'In this scenario, is the behaviour of select() undefined?' Many thanks Andy On Fri, 7 Feb 2003, Jerry Feldman wrote:
Having done my share of using select (mostly on commercial Unix systems), I think the only issue that I can see here is that your file descriptor is not really attached to a stream via one of the appropriate functions, such as listen() or connect(). I would think that the behavior is undefined. Why it would be different on the two libraries, I don't know.
-- Jerry Feldman <gaf@blu.org> Boston Linux and Unix user group http://www.blu.org PGP key id:C5061EA9 PGP Key fingerprint:053C 73EC 3AC1 5C44 3E14 9245 FB00 3ED5 C506 1EA9
On Fri, 7 Feb 2003 18:54:18 +0000 (GMT) Andrew Cheadle <amc4@doc.ic.ac.uk> wrote:
Hi,
Can anyone please explain the following behaviour. Consider the following:
int main( int argc, char **argv ) { int s; fd_set dread; fd_set dwrite; struct timeval to;
to.tv_sec = 3; to.tv_usec = 0;
s = socket( AF_INET, SOCK_STREAM, 0 );
FD_ZERO(&dread); FD_ZERO(&dwrite); FD_SET(s, &dread);
if (select(s + 1, &dread, &dwrite, (fd_set *) 0, &to) < 0) { fprintf(stderr, "Error in select(): errno=%d\n", errno); return errno; }
return 0; }
On a (Suse i386 linux) glibc-2.1.3-27 machine this blocks for the timeout of 3 seconds and the 'dread' fd_set is cleared and the select returns 0.
On a (Suse i386 linux) glibc-2.2.2-67 machine this returns immediately and the 'dread' fd_set is left untouched and the select returns a value of 1.
The program above is a toy that reproduces my problem, while calling select immediately on 's' may not be a meaningful thing to do, I just want to know what the correct semantics are and why they have changed.
Cheers
Andy
********************************************************************* * Andrew Cheadle email: a.cheadle@doc.ic.ac.uk * * Department of Computing http://www.doc.ic.ac.uk/~amc4/ * * Imperial College * * University of London * *********************************************************************
-- To unsubscribe, email: suse-programming-e-unsubscribe@suse.com For additional commands, email: suse-programming-e-help@suse.com Archives can be found at: http://lists/archive/suse-programming-e
********************************************************************* * Andrew Cheadle email: a.cheadle@doc.ic.ac.uk * * Department of Computing http://www.doc.ic.ac.uk/~amc4/ * * Imperial College * * University of London * *********************************************************************
I checked the Tru64 Unix man page. They keep their docs reasonably up to date. http://www.tru64unix.compaq.com/docs/base_doc/DOCUMENTATION/V51A_HTML/MAN/MA... "The select() function supports regular files, terminal and pseudo-terminal devices, STREAMS-based files, FIFOs, and pipes. The behavior of the select() function on file descriptors that refer to other types of files is unspecified. For sockets, a file descriptor for a socket that is listening for connections indicates that it is ready for reading when connections are available. A file descriptor for a socket that is connecting asynchronously indicates that it is ready for writing after a connection is established." While I think the above description covers it, if need be I could check with one of the developers. On Sat, 8 Feb 2003 12:06:57 +0000 (GMT) Andrew Cheadle <amc4@doc.ic.ac.uk> wrote:
Hi Jerry,
Thanks for your quick response.
As I said, I know it's not a meaningful thing to necessarily do. And indeed I should have said the behaviour is correct once the stream is properly attached.
I just happen to be working on a piece of legacy code that used the assumption that the select would block and I'm trying to determine if the assumption was ever valid ( you say not - you think behaviour should be undefined). So I guess my question is really:
'In this scenario, is the behaviour of select() undefined?'
Many thanks
Andy
On Fri, 7 Feb 2003, Jerry Feldman wrote:
Having done my share of using select (mostly on commercial Unix systems), I think the only issue that I can see here is that your file descriptor is not really attached to a stream via one of the appropriate functions, such as listen() or connect(). I would think that the behavior is undefined. Why it would be different on the two libraries, I don't know.
-- Jerry Feldman <gaf@blu.org> Boston Linux and Unix user group http://www.blu.org PGP key id:C5061EA9 PGP Key fingerprint:053C 73EC 3AC1 5C44 3E14 9245 FB00 3ED5 C506 1EA9
On Fri, 7 Feb 2003 18:54:18 +0000 (GMT) Andrew Cheadle <amc4@doc.ic.ac.uk> wrote:
Hi,
Can anyone please explain the following behaviour. Consider the following:
int main( int argc, char **argv ) { int s; fd_set dread; fd_set dwrite; struct timeval to;
to.tv_sec = 3; to.tv_usec = 0;
s = socket( AF_INET, SOCK_STREAM, 0 );
FD_ZERO(&dread); FD_ZERO(&dwrite); FD_SET(s, &dread);
if (select(s + 1, &dread, &dwrite, (fd_set *) 0, &to) < 0) { fprintf(stderr, "Error in select(): errno=%d\n", errno); return errno; }
return 0; }
On a (Suse i386 linux) glibc-2.1.3-27 machine this blocks for the timeout of 3 seconds and the 'dread' fd_set is cleared and the select> returns 0.
On a (Suse i386 linux) glibc-2.2.2-67 machine this returns immediately> and the 'dread' fd_set is left untouched and the select returns a> value of 1.
The program above is a toy that reproduces my problem, while calling> select immediately on 's' may not be a meaningful thing to do, I just> want to know what the correct semantics are and why they have changed.> Cheers
Andy
******************************************************************** *> * Andrew Cheadle email: a.cheadle@doc.ic.ac.uk *> * Department of Computing http://www.doc.ic.ac.uk/~amc4/ *> * Imperial College *
* University of London *>
*>> --
To unsubscribe, email: suse-programming-e-unsubscribe@suse.com For additional commands, email: suse-programming-e-help@suse.com Archives can be found at: http://lists/archive/suse-programming-e
********************************************************************* * Andrew Cheadle email: a.cheadle@doc.ic.ac.uk * * Department of Computing http://www.doc.ic.ac.uk/~amc4/ * * Imperial College * * University of London * *********************************************************************
Has anyone tried to install Java JRE and JDK so you can access it from Netscape. I'm doing the Sun Java Tutorial and Threading requires it for some of the functions.
participants (3)
-
Andrew Cheadle -
Craig Steffler -
Jerry Feldman