Design consideration (p)threads and Linux sockets

[ThomasWink]

I have a design consideration to make using multi threading (pthreads) to handle multiple client connections over tcp. On Linux. Keeping in mind that I am writing a (dynamic) thread pool.

That said, I came up with two different designs:

1. Employ some kind of queue structure/ linked list of connected clients and let the workers take them of the queue, mutex lock taking care of race conditions. The main thread will fill the queue with accepted connections.

or

2. Main thread will bind a socket and the workers will accept the client connections.c (the worker threads get a handle to the socket and just listen)
If my understanding is correct, the OS will decide handle which worker gets the connection

Which of these would be preferable/ best performing? Any suggestions or other possibly better solutions are welcome! I am here to learn

[Salem]

If you want to learn, then I suggest you prototype both approaches to see what is likely to happen.

"preference" and "best" are subjective in so many ways.

Also, what is the cost of servicing a client connection compared to the overhead of accepting and managing the connection in the first place.
If your service is to verify whether 100-digit numbers are prime, then that's going to be the elephant in the room. Your connection manager just needs to work.

[ThomasWink]

I will certainly try both designs for the sake of learning.

I see your point, overhead on connection management is not a great concern (usually) when dealing with tcp connections.

[ddutch]

I recommend the use of epoll (Linux only). See for example How to use epoll? A complete example in C - Banu Blog
That might be more efficient then the use of pthreads and mutexes. I combined it with linked lists

[ddutch]

although .... epoll might have disadvantages, for example if you do not have to handle large amounts of clients at the same time and you still might need some threads. Also epoll is a bit more complex.