Efficent handling of sockets

[Ken Burtch]

Thanks for everyone's feedback.  It was appreciated.

-----------------------------------------------------------------------------
Ken O. Burtch                                       Phone/Fax: 905-562-0848
   "Linux Shell Scripting with Bash"                  Email: ken-8VyUGRzHQ8IsA/PxXw9srA at public.gmane.org
   "Perl Phrasebook"                 Blog: http://www.pegasoft.ca/coder.html
-----------------------------------------------------------------------------

On Thu, 19 Feb 2009, D. Hugh Redelmeier wrote:

> | 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
>
--
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