At Highgroove, we’re efficient. We ride our bikes to work (most of the time). We conserve our clients time, resources and file descriptors. File what?
That’s right, we conserve file descriptors.
Here’s the story. I recently introduced one of our clients, let’s call him Careful Carl, to the concept of file descriptors. Since Careful Carl’s first
language is Ruby, he wasn’t familiar with the underlying UNIX based mechanisms of file descriptors. One of the neat thing about file descriptors are that they are a limited resource.
Try running “ulimit -n” to see how many are available to a given process in your system. Traditionally this number was low in shared resource systems to insure that a particular user did not hog the shared system resources.
In the course of my explanation, Carl decided we should audit the current application for hanging file descriptors. We grepped through the code for
“open” and found a few instances that needed some developer attention. They looked something like this.
The question remained, “How do we know that file descriptors are leaked?” We see that the file isn’t closed but really, how do we know for sure??
Thank goodness for Aman Gupta’s presentation. We were well equipped to determine what files were opened and used by our wasteful, rude code.
Wow, our suspicion was confirmed. Ultimately, we were leaking FDs in about five or six different places in the project. Fortunately, the solution is rather simple. Replacing “YAML::load(File.open…” with “YAML::load_file..” solved all our problems. (Well, at least all the problems related to leaking file descriptors.)
Yep, we’re good.
The file descriptors are all safe and sound and conserved. Careful Carl’s happy. Job well done.
How many FDs have you conserved today?
Thanks to Highlights for file name ideas