Re: Asynchronous IO

2001-04-20 Thread Stephen C. Tweedie
Hi, On Fri, Apr 13, 2001 at 04:45:07AM -0400, Dan Maas wrote: > IIRC the problem with implementing asynchronous *disk* I/O in Linux today is > that the filesystem code assumes synchronous I/O operations that block the > whole process/thread. So implementing "real" asynch I/O (without the > overhe

Re: Asynchronous IO

2001-04-13 Thread Christopher Smith
--On Friday, April 13, 2001 04:45:07 -0400 Dan Maas <[EMAIL PROTECTED]> wrote: > IIRC the problem with implementing asynchronous *disk* I/O in Linux today > is that the filesystem code assumes synchronous I/O operations that block > the whole process/thread. So implementing "real" asynch I/O (with

Re: Asynchronous IO

2001-04-13 Thread Dan Maas
IIRC the problem with implementing asynchronous *disk* I/O in Linux today is that the filesystem code assumes synchronous I/O operations that block the whole process/thread. So implementing "real" asynch I/O (without the overhead of creating a process context for each operation) would require re-w

Re: Asynchronous io

2001-04-12 Thread Bart Trojanowski
Hi CJ, you should really read the thread titled "Linux's implementation of poll() not scalable?" in the LKML archives, here is a link: http://www.uwsg.iu.edu/hypermail/linux/kernel/0010.3/0003.html There are many problems with the /dev/something interface for events and all is described in that

Asynchronous io

2001-04-12 Thread CJ
//Linux really needs a clean basis for asynchronous and //unbuffered i/o libraries. Something like the fork/thread //clone(), but to replace select() and aio_* polling. This //might be a start. And it is just a file and very like a //pipe or socket. //Suppose we add /dev/qio with 64 byte sect