> 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.
> Note that glibc 2.1 has the aio_*() functions, which give you what you
> want with reading and writing.
I'm going to use them instead, only I'm not going to glibc so I'll backport
the code or see if I can munge mine to the right API.
I think I need a new pthreads, seems broken at the moment, with libc5
anyhow.
> 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.
Followups should probably be off the list.
-cw
-
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