Messages in this thread | ![/](/images/icornerl.gif) | | From | (Matthias Urlichs) | Subject | Re: InfoWorld web server shootout# | Date | 11 Jul 1997 07:28:59 +0200 |
| |
In dist.linux.kernel, article <868579677.28875@noris.de>, "David S. Miller" <davem@jenolan.rutgers.edu> writes: > From: alan@lxorguk.ukuu.org.uk (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 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
| ![\](/images/icornerr.gif) |