> David Schwartz wrote: > >> 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".
> > This is a much slighter misunderstanding. The result of the 'select' > > function tells you nothing about what a particular 'read' will > > or will not do. > The docs 'precisely' says that it does. I'm sorry if you cannot trouble > yourself to read the man pages to address your issues with the correct > functionality of the select call. No, that's not what the docs say. That's what the docs are frequently misunderstood to say, but that is not what they actually say. When they say, for example, "see if a read will not block", they mean a hypothetical concurrent read that does not take place, not a future actual read. It's bad wording, but it is not incorrect unless you choose to misunderstand it. For example, one could write that the 'access' function tells you if an "'open' will succeed", but that doesn't mean an 'open' after an 'access' *must* succeed. Like all status-reporting functions, 'select' tells you information that is accurate at some point in-between when you called it and when it returned that value to you. But it makes no predictions about the future, and the documentation does not say that it does. It does imply that it does, and that's why it's important to correct this misconception whenever it comes up. POSIX's documentation is a bit clearer, saying "would block" rather than "will block". This helps to make it clear that we're talking about a hypothetical concurrent operation, not an actual future one. DS - 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/