> David S. Miller wrote:
> > The problem, for one, with web etc. servers is the incoming connection
> > socket. If you could tell select/poll "hey, when a new conn comes in,
> > wake up one of us", poof this issue would be solved. However the
> > defined semantics for these interfaces says to wake everyone polling
> > on it up.
>
> Apache handles this very nicely. It runs a group of processes,
> and each *blocks* on accept(2). When a new connection comes in,
> the kernel wakes up one, which handles that socket alone, using
> blocking I/O (it uses alarm(2) to do timeouts).
>
> This way they avoid the poll/select issue entirely.
>
> [This applies to Apache 1.2, not sure about later versions]
1.2 actually will still use select() and then do an accept() immediately
after -- it doesn't treat the single and multiple socket cases
differently. 1.3 fixes this oversight.
But this all falls apart as soon as you ask apache to handle multiple
sockets (i.e. 80 and 443). See
<http://www.apache.org/docs/misc/perf-tuning.html>, search for "accept
Serialization" for my discussion of why it falls apart... and explanation
of why Apache uses fcntl() to serialize things (or flock() or any number
of other interprocess synchronization primitives).
That's a case where Apache would really like to tell the kernel "here's a
list of listening sockets, accept a connection and return me an fd,
thanks".
1.3 also fixes another starvation condition not documented on that page --
if you always scan your sockets from 0 to N, and your server has a really
busy socket early on, then it is possible to starve the higher numbered
sockets. i.e. if socket 3 is port 80, and socket 4 is port 443, and all
the children/threads/whatever always test 3 for new connections first it's
possible that 4 will be starved. 1.3 cycles through the list... this is
another example of things that can be done a lot more efficiently with
completion ports (or an isomorphic technology).
Dean
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu