Efficent handling of sockets

[D. Hugh Redelmeier]

| From: Lennart Sorensen <lsorense-1wCw9BSqJbv44Nm34jS7GywD8/FfD2ys at public.gmane.org>

| I use pthreads instead, and launch a thread for every incoming request.
| It might be a problem if you actually have thousands of simultanious
| connections.
| 
| Since each thread only has a single connection to listen for, there is
| no searching needed.

Threads are a very general purpose mechanism and are implemented quite
expensively compared with a reasonable "get next event" loop.

| I don't like select very much personally.

Why?

But, for high efficiency, with thousands of file descriptors, other
mechanisms exist that don't have to shovel large bitstrings in and out
of the kernel at every call.  (I don't do this so I don't remember the
details. epoll(7), I think, but what horrible man pages.)

| Also with a single thread and select, you can only be processing one
| request at a time, while with threads you could be using multiple CPUs
| and handling multiple sockets at once.  Locking of course is an issue
| to deal with for threaded code.

With select, you can (should) process all the things that come ready at the
time of the select call returning.  Under load, this is likely to be
more than one (heck, that is a symptom of heavy load).

This matters because often it is the process switching that is
expensive rather than the actual transaction processing.

If some (but not all) transactions are expensive to process, they can
then be farmed off to other threads or processes.

Anecdote:

I first realized this when I talked with the designer of a board to
handle 64 (I think) serial lines.  I always thought interrupts were
the way to go, but they found polling worked better for the worst
case.  If you can handle the worst case, the rest is easy.
--
The Toronto Linux Users Group.      Meetings: http://gtalug.org/
TLUG requests: Linux topics, No HTML, wrap text below 80 columns
How to UNSUBSCRIBE: http://gtalug.org/wiki/Mailing_lists