Messages in this thread |  | | Date | Thu, 8 Feb 2001 00:15:13 +0100 | From | Pavel Machek <> | Subject | Re: [Kiobuf-io-devel] RFC: Kernel mechanism: Compound event wait |
| |
Hi!
> > > Reading write(2): > > > > > > EAGAIN Non-blocking I/O has been selected using O_NONBLOCK and there was > > > no room in the pipe or socket connected to fd to write the data > > > immediately. > > > > > > I see no reason why "aio function have to block waiting for requests". > > > > That was my reasoning too with READA etc, but Linus seems to want that we > > can block while submitting the I/O (as throttling, Linus?) just not > > until completion. > > Note the "in the pipe or socket" part. > ^^^^ ^^^^^^ > > EAGAIN is _not_ a valid return value for block devices or for regular > files. And in fact it _cannot_ be, because select() is defined to always > return 1 on them - so if a write() were to return EAGAIN, user space would > have nothing to wait on. Busy waiting is evil.
So you consider inability to select() on regular files _feature_?
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"?
> 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()". Pavel -- I'm pavel@ucw.cz. "In my country we have almost anarchy and I don't care." Panos Katsaloulis describing me w.r.t. patents at discuss@linmodems.org - 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/
|  |