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... -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
