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