In message <200004022303.QAA00930@Greyhawk.DSG.Stanford.EDU>, you write: 

[...]

-> 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?)

I'd certainly buy it, seeing as I'm currently using Linux for this exact
reason for a certain application.  Scaling an event-driven server to tens
of thousands of connections in actually very easy (and from my benchmarks
quite performant) using this model.  I'd love to get a similar interface 
for NetBSD.

The other choice is to do all the network processing in the kernel via
STREAMS (if your OS of choice has 'em and you're into S&M 8-), or to build
an application-level-framing system (like the MIT exokernel and stuff that's
derived from it).  In both cases, the environment is much more constrained 
than your generic *NIX userland APIs, which makes it much harder to use if 
you're doing something other than pure packet processing (or serving of 
mostly static content).

--rafal

----
Rafal Boni                                                  rafal@mediaone.net