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
>
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
overhead
--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
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
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
--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 (without
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
//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
//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
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
10 matches
Mail list logo
