lkml.org 
[lkml]   [2001]   [Feb]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [Kiobuf-io-devel] RFC: Kernel mechanism: Compound event wait
    Hi!

    > So you consider inability to select() on regular files _feature_?

    select on files is unimplementable. You can't do background file IO the
    same way you do background receiving of packets on socket. Filesystem is
    synchronous. It can block.

    > It can be a pretty serious problem with slow block devices
    > (floppy). It also hurts when you are trying to do high-performance
    > reads/writes. [I know it hurt in userspace sherlock search engine --
    > kind of small altavista.]
    >
    > How do you write high-performance ftp server without threads if select
    > on regular file always returns "ready"?

    No, it's not really possible on Linux. Use SYS$QIO call on VMS :-)

    You can emulate asynchronous IO with kernel threads like FreeBSD and some
    commercial Unices do, but you still need as many (possibly kernel) threads
    as many requests you are servicing.

    > > Remember: in the end you HAVE to wait somewhere. You're always going to be
    > > able to generate data faster than the disk can take it. SOMETHING
    >
    > Userspace wants to _know_ when to stop. It asks politely using
    > "select()".

    And how do you want to wait for other select()ed events if you are blocked
    in wait_for_buffer in get_block (former bmap)?

    Making real async IO would require to rewrite all filesystems and whole
    VFS _from_scratch_. It won't happen.

    Mikulas

    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    Please read the FAQ at http://www.tux.org/lkml/

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