error conditions and select

[chris at umcp-cs.UUCP]

In article <19476 at rochester.ARPA> stuart at 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 at umcp-cs		ARPA:	chris at mimsy.umd.edu