re: disk-based fds in select/poll

Pierre Phaneuf <[EMAIL PROTECTED]> wrote: > It's fairly widely-known that select/poll returns immediately when > testing a filesystem-based file descriptor for writability or > readability. > > On top of this, even when in non-blocking mode, read() could block if > the pages needed aren't in core

Re: disk-based fds in select/poll

> 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 You could fix select to return when the page was cachied and return EWOULDBLOCK on reads if the page was not present to be honest. I don't think that

Re: 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 sub

Re: disk-based fds in select/poll

> 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 rea

disk-based fds in select/poll

Pardon me if some parts of this seem clueless. While I'm no newbie in userland, kernelspace I don't play in very often... It's fairly widely-known that select/poll returns immediately when testing a filesystem-based file descriptor for writability or readability. On top of this, even when in no