On Thu, 21 Apr 2011 17:04:58 +0200 Arnd Bergmann arnd@arndb.de wrote:
On Thursday 21 April 2011, Jesse Barnes wrote:
Client apps also have to worry about the fd count, since depending on the app and object caching policy it's very easy to get over 1024 objects. But the solutions above may work for that case as well; I don't expect many apps rely on select(), and those that do can fairly easily be converted.
Hmm, I think client apps are a much harder problem, because they are not under a central control. Note that there may be libraries using select(), so you would not be able to link to those, and you'd also need to solve the ulimit problem here.
For exising apps especially that's an issue. Lots of apps use external libs via NDK.
But there's another option for those: put the unified mm fds in "high" fd space. I think there are patches floating around to do that on glibc and Linux, which makes things easier in general for libraries that want to allocate their own fds, and other C libraries could implement something similar, assuming we had kernel support.