lkml.org 
[lkml]   [1999]   [Sep]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectHigh Performance I/O stuff (more)
Date
From
I did research this weekend on high performance I/O.  I looked at differerent
approaches and to me they all appear the same (I know that I will get some
flamage for this). The two most prominent models that I saw were IO
Completion Ports and Synchronous Events (such as the Gaurav
http://www.cs.rice.edu/~gaurav/papers/usenix99.ps).

I think that both of these models are basically the same. They both have
an event queue that you pick up events from. The only way that they differ
is in what they call an event. Completion ports take asynchronous opperations
and queue an event when the opperation completes (hence the name). Synchronous
events do the opposite: they queue an event when an opperation is possible
and then the synchronous (usually, non-blocking) opperation is performed.
From this, you can decouple and event queue from what you call an event.

From what I can see either model will give roughly the same performance,
as they both do roughly the same amount of work. The one benefit that seems
to exist for the Completion Ports model is that there are fewer contex
switches.

Now, looking at POSIX.1b signals and signal queues and getting some
information from Stephen Tweedie it looks like completion ports are doable
without anything new, I think that I have decided.

If you find an available signal, set the handler for it, the block it,
this signal number now effectively becomes the completion port. You then
can fcntl() a file descriptor with F_SETSIG and the signal number. Then to
fetch the blocked signals, use sigwaitinfo(). I guess you could also use
aio_{read,write}() and set sigevent appropriately. This actually seems
preferable since you can then use aio_return() to find the return value
out and use aio_cancel() to cancel the request if wanted.

The one drawback that I see to this is that it can only really handle
aio_{read,write}() and {read,write}()/fcntl(). Any other events such as
thread/child deaths cannot really be worked into this scheme unless you
could set the signal they deliver on termination.

If you really wanted to, you could have signals delivered for the ability
to read/write to a file descriptor and then you would have Gaurav's model.

Basically, unless anybody can see anything wrong with this get to work
implementing!

-jason


-
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:54    [W:0.914 / U:0.028 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site