chris@umcp-cs.UUCP (07/20/86)
In article <19476@rochester.ARPA> stuart@rochester.ARPA (Stuart Friedberg) writes: >1) Whenever a selected file descriptor changes state in any way, >select will wake up. If the state change was an error condition or >anything related to the status of a device or connection, both the >input AND the output masks will be filled in. ... because either input or output will return immediately with that error indicated. This seems reasonable (though it would, I think, make a bit more sense to call that an `exceptional condition'). >2) If a device or connection has been closed (on the other end) the >appropriate thing to do is close it on your end. Unless you do, >select will continue to tell you about it. (And you will continue to >tie up resources) Unix seems in general to treat `end of file' as a very natural condition, so calling it an exception might be a bit odd. If you had a connected socket and it has been closed at the other end, it is now useless anyway. >3) There is no good way to find out what exactly happened to the >file descriptor in general. Quite true. >Although the FIONREAD ioctl gives useful information, Actually, it gives unreliable information, if (e.g.) there is a temporary error condition. There may be data to read even if there is also an error pending. >you can't find out exactly what the new condition is >unless you try to read or write from it. In 4.3, you can use `getsockopt' with SO_ERROR to pick up the error (if any) from a socket, but there is nothing you can do with a tty, for example. >It is my belief that the original designers of select did not intend >this to happen ... Any comment from the V8 folks? >For programs with simple control structure this "feature" of select >is not too bad a problem. For complicated programs that are trying >to be robust against failure (that means we don't just die when we >get an error, we identify it and try to do something about it, like >maybe go out and locate a secondary server), it becomes a pain in the >neck. It is not *that* bad: just hold on to the data you were about to transmit (it has not been altered by the write or send). >While I'm showing my irritation in public, I also wish that stat >reported something useful (ie, not a zeroed buffer) for sockets. >After two major releases with sockets (4.2, 4.3), why doesn't it? It (usually?) reports at least a block size. What do you want it to do? (Think carefully about that before you use up all of the stat structure!) >But even stat doesn't tell you everything you'd like to know. I'd >like to be able to get at the connection status (which is protocol/ >device dependent) and the error status (which generally isn't) >and I can't get at either of those without trying to do IO. You *can* get the error status, at least in 4.3, as I mentioned. >Let me quote two paragraphs from a report Derek Pitcher and I >wrote recently: > > "The situation is slightly more complicated than just > described for three reasons. First, the designers of select > made provision for a third bit mask. This mask was intended > for "exceptional conditions" on a file descriptor or a > socket. This mask has never been implemented. Not true! 4.3 implements out of band data as an exceptional condition on sockets. I think this is the only exception now implemented, though I cannot be certain without checking. > Instead, when an exceptional condition occurs, Ah, but you have not yet defined `exceptional conditions'. Is an error an exception? (I think so.) What about out of band data? (Berkeley thinks so.) What else? [much deleted] > "In programming the router we had to detect and handle enough > exceptional conditions to fervently wish that select had > been fully implemented. We would like to treat events like > "new connection available", "pending connection > established", and "existing connection dropped or refused" > differently from the routine operations of forwarding data > between users. [...]" `New connection available' has been defined as an `input' condition on a listen()ing socket. The other two are indeed hard to ascertain. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 1516) UUCP: seismo!umcp-cs!chris CSNet: chris@umcp-cs ARPA: chris@mimsy.umd.edu