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
valid.)
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
accept().
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: urlichs@noris.de
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="http://info.noris.de/~smurf/finger">here</A>. 42