Creating socket file descriptors(sock fd) in a multi-threaded application

Question

I have a multi-threaded application having 2 threads. Each thread services a different interface. Whenever a message needs to be sent out through an interface, the corresponding thread opens a socket(gets a fd) and sends the message and closes the fd. The problem is, when I have both the threads running, the sockets are not getting reused, I see fd number to increase inside /proc//fd. I can also verify this from the logs.

The believe the problem is that the thread requests a fd even before the other thread closes it's fd. So the OS returns the next available fd number and this keeps going on.

Thread 1 opens a tcp socket and thread 2 opens a can(controller area network) socket

time thread1 thread2
 0 req fd idle
 1 fd 1 req fd
 2 close fd1 fd 2
 3 req fd close fd 2
 4 fd 3 req fd
 5 close fd 3 fd 4

I believe this is what it would look like if I were to write it down. How can I make sure that the fd number doesn't keep growing? I am running 32 bit linux on an ARM processor.

• user3657941: What kind of sockets?
• bhargava_sg: Thread 1 opens a tcp socket and thread 2 opens a can(controller area network) socket
• smac89: Posix sockets I assume?
• user3657941: I am guessing that you are using some kind of embedded operating system running on an 8-bit micro-controller if the maximum file descriptor value is 127. Don't close the sockets. There should be no need.
• bhargava_sg: @DavidCullen, I am running 32 bit linux on an ARM processor. I was returning the sockfd as int8_t and that explains the 127 limit. But I still want to know how I can make sure the fd number does not grow. The software architecture is such that every message is sent as a new connection so I can not change that.

Answer 1

The gaps in socket descriptor values are not an evidence of a resource leak. Allocating a file descriptor is a thread-safe operation (probably, as are all system calls). If you close each socket properly, there will be no leaks.

You can monitor how the number of open file descriptor changes with the following command:

watch --interval=0.5 "sh -c 'lsof -p YOUR_PROGRAM_PID_HERE | wc -l'"

If the number grows, then probably there are some sockets (or other FDs) not closing.

If you are still not sure if there are descriptor leaks, you may try to count number of open file descriptor programmatically at the exit of your program, either by examining number of entries at /proc/self/fd directory, or by repeatedly trying to close all descriptors and counting how many calls did not return EBADF error. If this number is different each time, then probably there are leaks.

Answer 2

Turns out, in the can code at one condition I was not closing the fd!