Messages in this thread | | | From | "David Schwartz" <> | Subject | RE: SELECT() returns 1 But FIONREAD says (Input/output error) | Date | Thu, 31 May 2007 18:01:31 -0700 |
| |
> i am using the GARMIN_GPS/usb driver to read a gps receiver. > In testing the ability of my software to recover from various errors, I > try this: unplug the gps/USB cable from the usb hub. > > Interestingly enough the thread spins. > the SELECT() waits for something to happen, and I get one channel that > something interesting happened. > Then i try to find out how many chars are in the read buff via FIONREAD. > That call errors out with an i/o error. > > Needless to day, the code resets the SELECT parameters, and SELECT is > called again. It again says that something interesting has happened on > that ( i/o errored ) channel. And we now repeat the FIONREAD. > > In this case what, will reset the "something interesting has happened" > report from the SELECT call? Will it ever be reset in this case?
Nope. An errored connection is always ready for read/write -- there is nothing to wait for as far as the kernel is concerned. Your code keeps asking the kernel if something interesting has happened, the kernel keeps telling it yes, and it refuses to do anything about it.
At minimum, a detection of an error condition that could be persistent should be followed by a delay. A detection of an error condition that has in fact persisted and was previously detected should *never* be followed by an immediate return to 'select'.
You need to *handle* the I/O error. Backoff might be one way, sleeping for an increasing amount of time after each fatal error, subject to some limit.
And why are you calling FIONREAD? Just 'read' the data -- you're going to have to eventually anyway.
DS
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |