| |||||||||||||
More fun with file descriptorsMore fun with file descriptorsPosted Jun 14, 2007 13:43 UTC (Thu) by davecb (subscriber, #1574)Parent article: More fun with file descriptors Odd, I recollect building apps which used high-numbered FDs via a well-known idiom, below. I would expect that anyone who needed to grab an FD for out-of-band use would use something like
if (fstat(maxFd, &stat_buf) == -1) {
/* It's not in use, so grab it. */
if (fcntl(confFd, F_DUPFD, maxFd) != -1) {
/* Turns off FD_CLOEXEC as a sideffect. */
UTIL_CLOSE(confFd);
confFd = maxFd;
}
}
maxFd--;
Does that mean this ia not as well-known in the application-design world
as one would expect? It's the problem that motivated adding
fcntl(F_DUPFD) to the system, after all.
--dave
(Log in to post comments)
More fun with file descriptors Posted Jun 14, 2007 14:41 UTC (Thu) by nix (subscriber, #2304) [Link] That works fine in apps, but not in libraries. If a library wants to open some persistent fd, it currently has no guarantee that the app hasn't closed that fd on it, or dup2()ed another one over the top of it. I've seen problems with syslog() caused by exactly this in the past, and even problems with the three standard fds (buggy app closes them all rather than opening /dev/null three times and wackiness ensues.)
More fun with file descriptors Posted Jun 14, 2007 14:52 UTC (Thu) by davecb (subscriber, #1574) [Link] Hmmn, any app writer who kills his own syslog get exactly whatthey deserve (;-))
Joking aside, the code snippit was from a LD_PRELOAD library that
I suspect normal evolution will prune out the exceptions over
--dave
More fun with file descriptors Posted Jun 14, 2007 18:24 UTC (Thu) by vmole (guest, #111) [Link] Hmmn, any app writer who kills his own syslog get exactly what they deserve (;-)) Any syslog that allows the user app to kill it through normal standard procedures (e.g. closing fds for a daemon) is broken. :-) Unfortunately, this is one of those cases where you have to know something about the underlying libc implementation to avoid screwing yourself. In particular, most of the implementations I've worked with only break if you've called openlog().
More fun with file descriptors Posted Jun 15, 2007 19:12 UTC (Fri) by giraffedata (subscriber, #1954) [Link] Any syslog that allows the user app to kill it through normal standard procedures (e.g. closing fds for a daemon) is broken. :-) It's not that you have to know the underlying libc implementation. Rather, you have to know libc's requirements of its environment. You don't leave a file descriptor open because you know syslog functions use it; you leave it open because the syslog facility requires you not to mess with any file descriptor you didn't create. There are dozens of ways a library places requirements on its environment because of resources shared among all code in the process. Some of the requirements are easily accepted, such as that a caller should not write over any memory it did not allocate (which allows the library to keep memory of its own). Sometimes the requirements are onerous, but "broken" is too strong a word for a library with inconvenient requirements. "less useful" or "dangerous" are better descriptions. Signal handlers, alarms, environment variables, stack space, terminal display space, Standard Error file contents, etc. are all controversial.
More fun with file descriptors Posted Jun 15, 2007 19:01 UTC (Fri) by giraffedata (subscriber, #1954) [Link] If a library wants to open some persistent fd, it currently has no guarantee that the app hasn't closed that fd on it, or dup2()ed another one over the top of it. But that's also true of the kernel modifications being proposed. And it's similar to the risk that the app will write over memory that was malloc'ed by the library. The app and library, in a single thread, can stay out of each others' way with the F_DUPFD method if they observe obvious protocol. That is in contrast with simple open(), in which a library call can defeat its caller's assumptions of sequentially allocated file descriptors. What the kernel proposal has that F_DUPFD doesn't is that 1) it works even multithreaded (the F_DUPFD method requires the library to temporarily to use a low FD, and another thread could see that) and 2) it allows the high fds to be higher (today, the maximum fd is quite low because of the way the kernel data structures are).
More fun with file descriptors Posted Jun 14, 2007 16:15 UTC (Thu) by zlynx (subscriber, #2285) [Link] I believe the context of the whole file descriptor discussion involves threading and the bad performance of high file descriptors.
If your library wants to dup2 a high file descriptor, another library could be trying the same trick in another thread and screw up the whole thing if it happened at just the right point between your fstat and the dup.
The performance problems happen because of the way file descriptors are handled in-kernel.
|
|||||||||||||