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