Amos Waterland wrote:
> When you say that it is 'not done for files', does that mean that it is
> not done by design, and no plans exist to implement it for files
> (perhaps because completion notification is fundamentally different than
> readiness notification?), or that the work just has yet to be done?
> Thanks.
It isn't implemented for files, per POSIX I believe - in the same way
that select() will always return readable and writable on files.
I believe (i.e. I assume in my code ;-) that you should treat a SIGIO as
something which occurs when an fd transitions from "not readable" to
"readable", or from "not writable" to "writable". This applies even to
sockets: if you read only part of the readable data from a socket, then
you won't receive a SIGIO just because there is more unread data.
If the fd is permanently "readable" and "writable", such as with a file,
then there is no transition. Following this logic, you don't actually
need a special case for different kinds of fd -- you just need to check
their status with poll(), select(), or by trying a read/write operation
and checking for EAGAIN.
Please, someone point out if this logic does not hold, thanks :-)
-- Jamie
-
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 : Sun Jun 30 2002 - 22:00:12 EST