> * Chuck Lever informs me that the signal queue might overflow, leading
> to lost completion notifications. There is no reasonable way for an
> application to recover from such a condition.
As far as I know, on a queue overflow, SIGIO is raised and you can select() or
poll() on your fds. This of course is going to be exceptionally slow on a
large number of descriptors, but it shouldn't happen often.
I believe the aio_* functions in glibc do handle SIGIO by default as a backup
when the queue overflows.
> * POSIX aio lacks a mechanism to request read polls. With completion
> ports, one may request an asynchronous read of 0 bytes--the completion
> is delivered when there is data to be read. Implementations of POSIX
> aio cause an aio_read() of 0 bytes to complete immediately, a useless
> semantic.
You can use F_SETSIG w/ an RT signal & SIGIO directly instead of the aio_*
functions and you will be notified when data is ready to be read on the
socket.
This isn't as simple as using the aio_* functions, but it will allow you a
method to eliminate poll()'s and select()'s most of the time.
However, I'm trying to imagine a need for a read poll which couldn't be
substituted easily with an aio_read() call and an example isn't coming to
mind.
I've checked a few OS's and they all say that a read w/ 0 byte specified will
return 0 immediately and have no other results which would be consistent with
the semantics of aio_read().
Jordan
-- Jordan Mendelson : http://jordy.wserv.com Web Services, Inc. : http://www.wserv.com- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/