no, it isn't a non-kernel issue. this must be done atomically wrt the
user level, so it must be done in the kernel. there's no good way for the
application (or library) to allocate a specific RT signal, so there must
be some form of "gentlemen's agreement" between libraries and application
as to which uses which signal.
> > * 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
alan, you can detect an overflow, but recovering from one is another
matter.
one might argue, though, that queue overflow is a good way to prevent
receiver livelock, and provide a nice smooth degradataion of performance
during system overload. it really depends on how dangerous is a queue
overflow to correct application behavior.
> > * 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.
asynchronous writev and sendfile are useful enough to want in many
applications. why should each application developer reinvent the wheel?
however, maybe this can be done in the user-space threads library, if
there was some nice way to allocate RT signal numbers.
- Chuck Lever
-- corporate: <chuckl@netscape.com> personal: <chucklever@netscape.net> or <cel@monkey.org>The Linux Scalability project: http://www.citi.umich.edu/projects/linux-scalability/
- 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/