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
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
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
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 * *********************************************************************