Re: [PATCH] nextfd(2)

[Colin Walters <walters@verbum.org>]

On Wed, 2012-04-04 at 13:10 -0400, Colin Walters wrote:

> The thing is, even if it were added today, since we need to run on old
> kernels, we'd have to carry the code to use the /proc trick
> approximately forever.  And in the end all nextfd() would accomplish
> would be a *third* case in the already messy ifdefs/fallbacks
> in the various implementations of process spawning.

The only really counterargument I see to this is if nextfd() were
*significantly* more efficient.  I happily switched to using eventfd()
instead of pipe(), while still carrying the burden of fallback code,
because dropping from two open descriptors to one solved actual
problems with maxing out 1024 fds.

As far as efficiency goes, I could imagine that as Linus said, what
you really want is nextfd(O_NOT_CLOEXEC), because in a well-behaved
program that marks its internal descriptors as O_CLOEXEC, the effort the
forked process spends closing them is just wasted over having it
all happen more efficiently in the kernel as part of the exec().

But if claiming efficiency, one needs to post benchmarks...