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/
This archive was generated by hypermail 2b29 : Thu Feb 15 2001 - 21:00:11 EST