lkml.org 
[lkml]   [2001]   [Jun]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: disk-based fds in select/poll
Alan Cox wrote:

> > I am thinking that a read() (or sendfile()) that would block because the
> > pages aren't in core should instead post a request for the pages to be
> > loaded (some kind of readahead mecanism?) and return immediately (maybe
> > having given some data that *was* in core). A subsequent read() could
>
> reads posts a readahead anyway so streaming reads tend not to block much

Ok, so while knowing about select "lying" about readability of a file
fd, if I would stick a file fd in my select-based loop anyway, but would
only try to read a bit at a time (say, 4K or 8K) would trigger
readahead, yet finish quickly enough that I can get back to processing
other fds in my select loop?

Wouldn't that cause too many syscalls to be done? Or if this is actually
the way to go without an actual thread, how should I go determining an
optimal block size?

Was there anything new on the bind_event/get_events API idea that Linus
proposed a while ago? That one had got me foaming at the mouth... :-)

--
Pierre Phaneuf
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 12:54    [W:0.041 / U:0.156 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site