[asterisk-dev] asterisk ast_close_fds_above_n, wtf?

[Paul Albrecht]

To summarize for those that like to keep score: you have conceded that
the "close on exec" flag can be used reliably on linux and now you're
arguing that the "close on exec" flag isn't portable.

Well so what? The closefrom system call isn't portable either so what's
your point? As the preferred platform for asterisk is linux you should
be writing your code to that system interface. If you want to port
asterisk to other platforms then use the preprocessor to conditionally
generate whatever code you need for them.

On Tue, 2011-05-17 at 13:51 -0500, Tilghman Lesher wrote:
> On Tuesday 17 May 2011 13:20:22 Paul Albrecht wrote:
> > Thought I'd start a separate thread because since some folks can't look
> > at patches submitted to the list...
> 
> All developers who have commit rights to the code aren't allowed to look at
> unlicensed patches.  It's a policy meant to protect the project from
> "tainting" the minds of developers who may unconsciously use code they see
> that is not licensed for inclusion under our licensing scheme.
> 
> > Here's my question: Why is asterisk supporting code, essentially the
> > solaris closefrom system call, to close file descriptors over exec
> > system calls?
> > 
> > This approach has been rejected by the glibc maintainer:
> > 
> > http://sourceware.org/bugzilla/show_bug.cgi?id=10353
> 
> Correct, because it really needs to be a kernel interface, as implemented
> on Solaris.  Because it's possible for a program to go directly to the
> kernel to open file descriptors, instead of through the library, the
> library cannot reliably verify that it has tracked all file descriptors.
> 
> > And as linux provides a satisfactory method to close file descriptors it
> > creates prior to exec'ing a program or script:
> > 
> > http://udrepper.livejournal.com/20407.html
> > 
> > what's the point another interface?
> 
> That's wonderful.... for Linux, as long as you're running kernel 2.6.27 or 
> above.  What if you're running FreeBSD?  Or Mac OS X?  Or Solaris?  Or
> CentOS 5.5 (a kernel less than 2.6.27)?  Those systems don't support 
> setting the CLOEXEC flag concurrently with the system call that opens
> the file descriptor.  You still have the same problem.  Asterisk supports
> all of these systems, so it needs a solution that works on all of these
> systems.
> 
-- 
Paul Albrecht