Linux中的线程/套接字限制

Question

First of all: sorry for my english. Guys, I have a trouble with POSIX sockets and/or pthreads. I'm developing on embedded device(ARM9 CPU). On the device will work multithread tcp server. And it will be able to process a lot of incoming connections. Server gets connection from client and increase counter variable(unsigned int counter). Clients routines will run in separate threads. All clients will use 1 singleton class instance(in this class will be opened and closed same files). Clients works with files, then client thread closes connection socket, and calls pthread_exit(). So, my tcp server can't handle more than 250 threads(counter = 249 +1(server thread). And I got "Resource temporary unavailable". What's the problem?

Answer 1

Whenever you hit the thread limit - or as mentioned run out of virtual process address space due to the number of threads - you're.... doing it wrong. More threads don't scale. Especially not when doing embedded programming. You can handle requests on a thread pool instead. Use poll(2) to handle many connections on fewer threads. This is prettty well-trod territory and libraries (like ACE, asio) have been leveraging this model for good reason

The 'thread-per-request' model is mainly popular because of it's (perceived) simple design.

As long as you keep connections on a single logical thread (sometimes known as a strand ) there is no real difference, though.

Also, if the handling of a request involves no blocking operations, you can never do better than polling and handling on a single thread after all: you can use the 'backlog' feature of bind/accept to let the kernel worry about pending connections for you! (Note: this assumed a single core CPU, on a dual core CPU this kind of processing would be optimal with one thread per CPU)

Edit Addition Re:

ulimit shows how much threads can OS handle, right? If yes, ulimit does not solve my problem because my app uses ~10-15 threads in same time.

If that's the case, you should really double check that you are joining or detaching all threads properly. Also think of the synchronization objects; if you consistently forget to call the relevant pthread *_destroy functions, you'll run into the limits even without needing it. That would of course be a resource leak . Some tools may be able to help you spot them (vlagrind/helgrind come to mind)

Answer 2

Use ulimit -n to check the number of file system handles. You can increase it for your current session if the number is too low.

Also you can edit /etc/security/limits.conf and to set a permanent limit

Answer 3

Usually, the first limit you are hitting on 32-bit systems is that you are running out of virtual address space when using default stack sizes.

Try explicitly specifying the stack size when creating threads (to less than 1 MB) or setting the default stack size with "ulimit -s".

Also note that you need to either pthread_detach or pthread_join your threads so that all resources will be freed.