I am writing a parallel TCP server that should handle multiple connections using the 'thread per connection' approach (using a thread pool ) My doubt is that this is the most optimal way for each thread to get a different file descriptor.
I found that the following two methods are most recommended:
- A main thread that
accepts() all incoming connections and stores its descriptors in the data structure (for example: a queue ). Then each thread can get fd from the queue. - Accept () is called directly from each thread . (Recommended in Unix Network Programming V1 )
The problems that I find for each of them are:
- The static data structure in which all fd is stored must be locked (
mutex_lock ) before the stream can read it, so in the case when a significant number of threads want to read at exactly the same moment I don’t know how much time will pass until everything they will not achieve their goal. - I read that the Thundering Herd problem with
accept() calls at the same time has not yet been completely resolved on Linux, so I might need to create an artificial solution for it that will ultimately make the application at least as slow as at approach 1.
Sources:
(Some links talk about approach 2: does-the-thundering-herd-problem-exist-on-linux-anymore - and one article I found about this (deprecated): linux-scalability / reports / accept.html
And SO answer recommending approach 1: can-i-call-accept-for-one-socket-from-several-threads-simultaneously
I am really interested in this, so I would be grateful for any opinion on this :)
source share