David Schwartz wrote:
David Schwartz wrote:
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.
The select() returns because i pulled the USB cable from hub. Seems
reasonable.
Good. Then there is nothing further to discuss.
The next select() found what? to be interesting in order to prematurely
terminate the select-wait? As far as I can tell, nothing interesting has
happened since the previous select(). In this case the select() is only
looking at read()'s.
You have a very serious misunderstanding of what 'select' does. The 'select'
function is level triggered and state based, not edge triggered or event
based. The situation was the same as before, and so the same result is
required.
The misunderstanding is from the docs.
The select() does not report device errors.
Select will just "more precisely, to see if a read will not block".
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]