Oh I do understand.
> * As far as I know, there is no way to allocate a POSIX real time signal
> number in a thread safe manner. There is no equivalent to the socket()
> system call--one must just pick a number and hope that no other thread
> in the same process just picked the same number.
So you write a library routine for it. Now that is hard. Its a non kernel
issue.
> * 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.
Incorrect. On an overflow you get a signal without rt information that tells
you there was a queue overlfow
> * 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 get a real time signal when there is now data to read, indicating the
file handle.
> * POSIX aio lacks asynchronous versions of writev() and sendfile().
> (Though the lack of an aio_writev() is made less important by TCP_CORK.)
Which you can do with another thread.
Alan
-
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/