[lkml]   [1998]   [Jul]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Non-blocking I/O
Chris Wedgwood <> 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 <>

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

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