Skip to contentSkip to conversation

disk-based fds in select/poll

DISCUSSION Dan Kegel 1 participant 1 message Jun 5, 2001

lore
Share & tools
lore

Dan Kegel

author
#0 lore raw
Quoted 13 lines · Pierre Phaneuf

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. sendfile() behaves in a similar way.

What would be needed to alleviate this?
...
I remember seeing a suggestion by Linus for an event-based I/O interface, similar to kqueue on FreeBSD but much simpler. I'd just say "I want it too!", ok? :-)

Quoted 3 lines

SGI's AIO might be a solution here, does it use threads? I'm trying to avoid context switching as much as possible, to keep the CPU cache as warm as possible.

IMHO, you want AIO. SGI's is fine for now. I hear rumors that there will be something even better coming in 2.5, though I have no details.

Or you could use explicit userspace threads... say, divide up your network connections among 8 or so threads. Then if one thread blocks, the others are there to usefully soak up the CPU time.

Readiness events for readahead completion on disk files used to seem like a neat idea to me, but now AIO seems more appealing in the long run, since they handle random access properly.

- Dan