Messages in this thread | | | Date | Sat, 26 Jul 2003 11:05:23 +0200 | From | Marco Roeland <> | Subject | Re: Repost: Bug with select? |
| |
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/
| |