[asterisk-dev] asterisk ast_close_fds_above_n, wtf?

[Paul Albrecht]

I got the impression that linux is the preferred platform form the
README in the top directory or the asterisk source directory. If that's
outdated perhaps you should "fix" it so it conforms to what it is
nowadays.

As for conceding the point, that's what you did and now that the
portability argument isn't working your back to well other libraries
don't use the flag.

This ignores the point I made in the previous thread which I'll restate:
asterisk has no business closing file or sockets it hasn't opened or
created.

You didn't acknowledge this or respond to it at that time so I simply
have to conclude you don't have the capacity to argue. You make
assertion without without expecting to justify them with supporting
facts. You state facts which are obvious, but that don't support your
assertions.

All of which is frustrating to say the least, but worse is the fact that
you lack the programming skills to actually do the work which is evident
by your coding the easy way rather than spending the time to fix the
problem correctly.

Really dude, if you put as much effort into coding as you do into
justifying lazy coding asterisk would be better.

By the way I don't know who "we" is but we're done dude. 

On Wed, 2011-05-18 at 09:53 -0500, Tilghman Lesher wrote:
> On Wednesday 18 May 2011 09:08:11 Paul Albrecht wrote:
> > 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.
> 
> I have not conceded that point.  We have external libraries linked into
> Asterisk, and as those libraries do not consistently use the CLOEXEC flag,
> those file descriptors may remain open in a child process with your
> approach, while they will be closed with the approach used in Asterisk.
> 
> > 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.
> 
> Thank you for your opinion on how you engineer your own projects.  We
> prefer uniting the code as best as possible for portability.  Our only
> limiting criteria is ensuring that the portability factor does not
> significantly impact Linux performance, and in this case, it does not.
> 
> If you feel that the CLOEXEC approach is better, then I suggest that you
> work with POSIX to get that approach (and corresponding kernel APIs) into
> a forthcoming edition of the Unix standard.  Following adoption of those
> API changes by the platforms we support, you are welcome to ask us to
> reconsider our approach at that time.
> 
-- 
Paul Albrecht