Fun with file descriptors
Posted Jun 7, 2007 14:24 UTC (Thu) by RobSeace
Parent article: Fun with file descriptors
> This problem is evidently real, to the point that the glibc goes out of
> its way to avoid using internal file descriptors for anything.
Um, except that it DOES use internal FDs for lots of stuff... How do you think syslog() is implemented? It needs a Unix domain socket FD to talk to syslogd... (Plus, it might open another FD for the console to blast messages there...) How do you think the DNS resolver works? It needs sockets to talk to DNS servers... Plus, there are countless opens of various "/proc" files and other regular files going on all the time... Granted, usually just very temporary, and closed soon after, but if we're worrying about multi-threaded code, that could still cause problems if they brokenly assume no one will be messing with the FDs... And, that's just libc; lots of other libs also open private FDs for their own use... Got an X app? You've got at least one hidden FD for talking to the X server... There are surely many other examples, as well... It's a fairly common practice, not something strange and unheard of... I just don't get why there needs to be a big deal made about it, and the sudden desire to cater to obviously and perversely broken apps... Continuing to enable these broken apps to function is not helping the situation any; the correct thing to do is fix the broken apps, not enable their broken behavior... Because, they're STILL going to break eventually, when they use some OTHER lib someday which uses FDs behind its back...
That said, I'm not really opposed to the idea of a separate FD space... I just don't see where its all that necessary... Anyone got an example of such a real-world broken app?? (And, if so, why the *bleep* isn't it fixed yet??)
to post comments)