Efficent handling of sockets

Lennart Sorensen lsorense-1wCw9BSqJbv44Nm34jS7GywD8/FfD2ys at public.gmane.org
Thu Feb 19 20:50:48 UTC 2009


On Thu, Feb 19, 2009 at 10:33:37AM -0500, Ken Burtch wrote:
>
> Any socket gurus out there?
>
> I had a question from a guy at work writing his own socket server in C.  
> He is writing an application which needs to handle thousands of users.
>
> He would like to know the most efficient way of servicing sockets.  
> Although he blocks on sockets with a select(2) call to the kernel, he 
> must still search thorugh the select list to determine which socket needs 
> to be serviced.  He would like to know if there is a more efficient way 
> to handle the socket stack.  In particular, he heard that there is a way 
> to have the kernel call a C function to processess particular sockets but 
> he doesn't know how to set that up nor is he certain if he has to use a  
> custom kernel module to achive this.  Can anyone give him pointers on how 
> to make searching through the select(2) results more efficient or give 
> him a more efficient alternative to select(2) for managing large numbers 
> of sockets?

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.

I don't like select very much personally.

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.

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





More information about the Legacy mailing list