Messages in this thread | | | Subject | Re: Non-blocking I/O | Date | Tue, 21 Jul 1998 20:51:14 +0300 (EEST) | From | Matti Aarnio <> |
| |
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
| |