On Tue, Oct 13, 2009 at 02:35:35PM -0700, Mark Crispin wrote: > On Tue, 13 Oct 2009, Oswald Buddenhagen wrote: >> this has nothing to do with baby-computer thinking. select() is simply >> an incredibly inefficient interface, as it requires transforming the >> bitmap(s) into wakeup lists on every call > > That is an implementation issue within the Linux kernel. There are other > possible implementations in which that interface would be more efficient, > no, it's an inherent problem. you won't realistically find a solution which works without wait queues (or whatever you call it). a polling bitmap is simply no data structure which fits well into an event-driven architecture of a heavily multitasked environment like an os kernel.
> and a poll() type interface less efficient. > afaict, poll() has no significant inherent advantages other than not limiting the permissible fds. in fact, with many fds to watch, the copying of the array poll() needs might actually have some impact, as opposed to the few dozen bytes select() needs. epoll() is a completely different interface. > The baby-computer thinking refers to an FD_SETSIZE that is lower than > the number of kernel fds. > that's rather meaningless reasoning given that the kernel numbers are adjustable and the relating #defines in the glibc code are explicitly documented as "ridiculously large". FD_SETSIZE is 1024 by default, because it always was like that. just like select() itself. i don't know why the glibc devs chose to make the FD_SETSIZE interface so arcane. the linux side of select() works just fine, except that nobody who needs real speed should seriously consider using it (on any platform). anyway, enough of that, i think. _______________________________________________ Imap-uw mailing list Imap-uw@u.washington.edu http://mailman2.u.washington.edu/mailman/listinfo/imap-uw
