Date: Wed, 15 Sep 1999 00:08:00 -0700 From: "Jayson Nordwick" <nordwick@scam.xcf.berkeley.edu> To: freebsd-hackers@freebsd.org Subject: High Performance I/O (more) Message-ID: <19990915070800.34512.qmail@scam.xcf.berkeley.edu>
next in thread | raw e-mail | index | archive | help
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: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19990915070800.34512.qmail>