Sorry it took me so long to get to this..

In message <20000323110156.A24213@rek.tjls.com>Thor Lancelot Simon writes
>On Thu, Mar 23, 2000 at 04:38:32PM +0100, PER4MANCE, J. Dolecek wrote:

[...]

>> http://www.usenix.org/publications/library/proceedings/usenix98/full_papers/
>banga/banga_html/banga.html
>> 
>> Seems interesting ... it would be good thing to have it in NetBSD, too.
>
>Actually, it looks to me like they only did the fdalloc() part, skipping
>the select() improvements that the paper suggests provide most of the
>performance benefit.

Thats a pity. I worked on a related project with Jeff Mogul last
summer; Gaurav's work was nice.  What we did was even better for some
apps:->, shame I havent found time to write it up.

But as I understand it, the real win comes from abandoning select()
and going to a getnextevent() API: register interest in (some set of)
events on a given FD, and the kernel remembers the set of interested
FDs, and notifies the app about events. None of this copying large
bitmasks or poll() arrays in and out every time.

Would anyone buy _that_?  (Assuming we could get the select()
improvements, which they kinda rely on?)