lkml.org 
[lkml]   [1998]   [Jul]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: Non-blocking I/O
    Date
    From
    Chris Wedgwood <chris@cybernet.co.nz> wrote:
    > On Tue, Jul 21, 1998 at 09:34:54AM -0400, Zachary Amsden wrote:
    > [I reformatted this because you evil nasty mta did bad things]

    Hmm... What do you mean with that ? (I am curious, as one of my
    larger hats is MTA writer.. Reply privately, this is off-topic to
    Linux. )

    > > Should be very easy indeed, just check for O_NONBLOCK when you are going
    > > to block a process waiting for disk I/O, and return the number of bytes
    > > read so far. Of course, all I/Os that you return EWOULDBLOCK on need to
    > > be scheduled so that at some point in the future they won't block. If the
    > > buffer cache locks in pages with pending transfer to userspace, I suppose
    > > it would also be wise to check for misbehaving processes chewing up a
    > > whole bunch of buffer cache with nonblocking I/O requests that they never
    > > service with some kind of timeout mechanism on the locks.
    >
    > For it to be useful, it need to be made to work with select(2) and poll(2)
    > much the same as sockets do.
    >
    > This looks decidely difficult to me.... <pause>.
    >
    > Actually, maybe not. Right now, I'm using a wrapper around libc which uses a
    > pool of threads for the IO, I could also wrap select and poll in a similar
    > way...

    That is propably the only way to handle things which are not
    non-blockable. Especially open() is such which can't return before
    the directory lookups, and lowest level file open succeeds or fails.

    While the network level can do connect() in fully non-blocked mode,
    the same is not quite so easy for open().
    Or could it be ? Davem ? Stephen ?

    File-IO on regular files is convertable into non-blocking. Consider
    for example current system of waiting for indirection blocks or data-
    blocks deep within filesystem codes. (Say, average random block access
    on the disk takes about 5 milliseconds. Instead of blocking for that
    the system could do retrying of the file-io in non-block mode to wait
    for the availability of the file block.)

    To realize that does need changes in the filesystem codes, though.
    A thing to consider in 2.3.* series.

    > hmm... what seemed very difficult now doesn't seem to hard. Will see later
    > perhaps.
    >
    > -cw

    /Matti Aarnio <matti.aarnio@sonera.fi>

    -
    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.altern.org/andrebalsa/doc/lkml-faq.html

    \
     
     \ /
      Last update: 2005-03-22 13:43    [W:0.024 / U:60.400 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site