Nope, this isn't about the select() limit. The soft limit on file handles should stay at 1024 so apps that use select() don't break. Apps like wine that have already switched away from select should be able to raise their soft limit if they want more file desciptors. Wine already does this. But ubuntu is misconfigured by default with a hard limit identical to the soft limit. It's time for ubuntu to fix this by raising the default hard limit on file desciptors in /etc/security/limits.conf. Users who need this can edit that file to make their games work, but they shouldn't have to.
(Topposted from my cellphone)
On Mar 25, 2011 8:03 AM, "Paul Chitescu" paulc@voip.null.ro wrote:
On Friday 25 March 2011 03:26:25 pm Dan Kegel wrote:
Scott, correct me if I'm wrong, but does Natt...
This is not an Ubuntu limitation but rather of the (g)libc API implementation.
At least on glibc it is possible to increase the FD_SETSIZE at build time. Been there, done that, got the T-shirt. No need for header patching.
http://yate.null.ro/websvn/filedetails.php?repname=yate&path=%2Ftrunk%2F...
Caveat: FD_... operations take longer if FD_SETSIZE is increased.
On all relevant platforms it is possible to check if a fd is above the limit. The application code must do so.
Best is to internally replace select() with poll() on platforms that support it.
Scott wrote:
So it turns out it's not a kernel config issue per se:
On 03/25/2011 06:05 PM, Tim Gardner wrote:
The initial hard limit value is not a CONFIG option... What is the issue with having upstart set this limit early in the boot cycle? Won't all new processes inherit the modified limit?
If that's a good idea then we need to retarget the bug
dank@eniac:~$ dpkg-query -S /etc/security/limits.conf libpam-modules: /etc/security/limits.conf
That's where the change should go. No need to modify the kernel.
-
Dan Kegel