lkml.org 
[lkml]   [1999]   [Sep]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: POSIX aio vs completion ports
Date
From
> You must not have understood the post you were replying to.  POSIX real
> time signal queues are inferior to completion ports in many ways.

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/

\
 
 \ /
  Last update: 2005-03-22 13:53    [W:0.130 / U:0.236 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site