On Friday July 25th 2003 at 17:20 uur Ben Greear wrote:
> I thought select is supposed to tell you when you can read/write at least
> something without failing. Otherwise it would be worthless when doing
> non-blocking IO because you can both read and write w/out blocking at all
> times. If you run similar code on a tcp socket instead of std-out, do you see
> the same busy spin? (To do it right, make sure the network between source and
> destination is slower than the CPU can handle, ie 10bt hub.)
My 'analysis' was indeed based on experience with sockets, where you
don't get the busy spin. It's indeed a bit baffling why select keeps
insisting that fd 1 is writable. A quick test on kernel versions
2.2.12-20, 2.4.20 and 2.6.0-test1 all give the same results, so I
suppose select itself is doing it's expected duty, and that in that case
the special underlying mechanics of stdout require special mechanics to
find out if it's blocked?! Beats me, but that's pretty easy... ;-)
Marco Roeland
-
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/
This archive was generated by hypermail 2b29 : Thu Jul 31 2003 - 22:00:28 EST