Messages in this thread | | | Date | Sun, 12 Sep 1999 14:55:05 -0400 (EDT) | From | Chuck Lever <> | Subject | Re: POSIX aio vs completion ports |
| |
On Sun, 12 Sep 1999, Alan Cox wrote: > > * 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.
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/
| |