Re: Non-blocking I/O

Richard Gooch (Richard.Gooch@atnf.CSIRO.AU)
Tue, 21 Jul 1998 18:52:43 +1000

Chris Wedgwood writes:
> On Tue, Jul 21, 1998 at 06:36:52PM +1000, Richard Gooch wrote:
>
> > Nope, not me. I'm fiddling with something else: reducing the impact of
> > select(2) and poll(2) when you have zillions of FDs.
>
> select(2) I don't think needs to work for gobs of FDs. In fact, I think its
> reasonable for select(2) to fail with then number of FDs is greater than say
> 1024.
>
> select(2) doesn't appear to be very scalable, and I don't see any reason to
> try to make it so...
>
> But, poll(2) should be nice as fast and be at worst O(n) for gobs and gobs
> of FDs, I'd like to have poll(2) working for 250,000 FDs at some point.

That O(n) behaviour is exactly the problem: as you get more FDs,
poll(2) takes longer and longer. For 250 000 FDs, you're talking
hundreds of milliseconds! That's each time you get activity on a
FD. This is no good for a HTTP server. I'm aiming for << O(n).

> > Doesn't help with open(2) since the aio_*() functions need a FD to work.
> > I've often wondered why we can't have non-blocking I/O with regular files.
> > It doesn't seem like it would be impossibly hard to implement.
>
> open(2) could reasonable be made to work with O_NONBLOCK.
>
> O_NONBLOCK is meaningless for read/write because its not clear what should
> happen and how you would make the code work in practice. I think O_NONBLOCK
> for read/write is asking fro trouble, unless I can think of a sane SAPI for
> it.

How's that? We have non-blocking I/O for reading and writing right now
for ttys, pipes and sockets. The interface is simple and well
understood. How is extending that to regular files a conceptual
problem?

> Followups should probably be off the list.

Erm, still looks on-topic to me (because of the part about
non-blocking I/O for regular files).

Regards,

Richard....

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html