On Tue, Oct 13, 2009 at 04:34:43PM -0700, Mark Crispin wrote: > On Wed, 14 Oct 2009, Oswald Buddenhagen wrote: > >>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. > > That's an interesting statement, considering that I spent many years > of my life doing kernel development on systems that had such bitmaps > with a multitasking event-driven architecture. > can you point me to some relevant works on that topic? you made me curious. ;)
> >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". > > Which is why the glibc #defines should come from the kernel. Even > if it is some variable in /proc, there is no reason why a build > shouldn't use the limit that the kernel was built to accomodate, > possibly rounded up to the nearest 1K. > i don't think the linux kernel has any arbitrary limitation (which wouldn't imply a really insane select() bitmap size, anyway). the only hard-coded values are the defaults of the ulimits. given that these change more or less periodically towards bigger values, compiling against that wouldn't be particularly meaningful, either. so glibc just uses its own arbitrary values which, by all practical means, work well enough. i'm sure there is a way to influence the limit, possibly as simple as #defining __FD_SETSIZE before including sys/types.h (of course, finding that out experimentally is *way* simpler than actually reading the glibc sources :D). _______________________________________________ Imap-uw mailing list [email protected] http://mailman2.u.washington.edu/mailman/listinfo/imap-uw
