Re: InfoWorld web server shootout#

Matthias Urlichs (
11 Jul 1997 07:28:59 +0200

In dist.linux.kernel, article <>,
"David S. Miller" <> writes:
> From: (Alan Cox)
> Date: Thu, 10 Jul 1997 18:46:57 +0100 (BST)
> Not easily. It opens a lot of races. If you have someone
> selecting() you need to wake at least one accept() caller up, and
> cope if they don't complete the accept "wake_up_one" is fun
> Really, people should revisit Linus's posting on select()
> wake_up_one() dangers from long ago. It is no trivial to preserve the
> sematics, if it is possible at all.

The problem is that we have just one wait queue but people with two
different semantics waiting on them (accept() vs. select()/poll()).

My proposal is to wake up one accept()ing process, if there is one, else
all the select()ing ones. Obviously, the accept() either clears the waiting
connection (if it subsequently failed) or it returns to userland with a new
socket. IMHO, if you're multithreaded you don't need to select() on
anything in the first place. (I'm aware that there are problems with this
approach. However, in the context of accept(), I think the statement is

How to implement that with just one wait queue is left as an exercise for
the reader, I'm afraid. Two possible solutions come to mind --
- set a flag somewhere while you're waiting in accept()
- implement two wait queues
- non-solution: Only one process/thread accept()s, the others wait on a
semaphore which that process raises as soon as it returns from the

Since I couldn't even easily identify the code which wakes up accept()ing
jobs, I have to leave any actual implementation in more capable hands. :-(

ARIES (Mar.21 - Apr.19)
       You are a wonderfully interesting, honest, hard-working person
       and you should make many new friends, but you won't because you've
       got a mean streak in you a mile wide.
Matthias Urlichs         \  noris network GmbH  /  Xlink-POP Nürnberg 
Schleiermacherstraße 12   \   Linux+Internet   /   EMail:
90491 Nürnberg (Germany)   \    Consulting+Programming+Networking+etc'ing
   PGP: 1024/4F578875   1B 89 E2 1C 43 EA 80 44  15 D2 29 CF C6 C7 E0 DE
       Click <A HREF="">here</A>.    42