Re: Linux's implementation of poll() not scalable?

From: Simon Kirby (sim@stormix.com)
Date: Tue Oct 24 2000 - 11:14:06 EST


On Mon, Oct 23, 2000 at 10:39:36PM -0700, Linus Torvalds wrote:

> Actually, forget the mmap, it's not needed.
>
> Here's a suggested "good" interface that would certainly be easy to
> implement, and very easy to use, with none of the scalability issues that
> many interfaces have.
>...
> Basically, the perfect interface for events would be
>
> struct event {
> unsigned long id; /* file descriptor ID the event is on */
> unsigned long event; /* bitmask of active events */
> };
>
> int get_events(struct event * event_array, int maxnr, struct timeval *tmout);

I like. :)

However, isn't there already something like this, albeit maybe without
the ability to return multiple events at a time? When discussing
select/poll on IRC a while ago with sct, sct said:

 <sct> Simon: You just put your sockets into O_NONBLOCK|FASYNC mode for
       SIGIO as usual.
 <sct> Simon: Then fcntl(fd, F_SETSIG, rtsignum)
 <sct> Simon: And you'll get a signal queue which passes you the fd of
       each SIGIO in turn.
 <Simon> sct: easy :)
 <sct> Simon: You don't even need the overhead of a signal handler:
       instead of select(), you just do "sigwaitinfo(&siginfo, timeout)"
       and it will do a select-style IO wait, returning the fd in the
       siginfo when it's available.

(Captured from IRC on Nov 12th, 1998.)

Or does this menthod still have the overhead of encapsulating the events
into signals within the kernel?

Also, what is different in your above interface that prevents it from
being able to queue up too many events? I guess the structure is only
sizeof(int) * 2 bytes per fd, so it would only take, say, 80kB for 20,000
FDs on x86, but I don't see how the other method would be significantly
different. The kernel would have to store the queued events still,
surely...

Simon-

[ Stormix Technologies Inc. ][ NetNation Communications Inc. ]
[ sim@stormix.com ][ sim@netnation.com ]
[ Opinions expressed are not necessarily those of my employers. ]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/



This archive was generated by hypermail 2b29 : Tue Oct 31 2000 - 21:00:13 EST