Wine should warn when ulimit -n needs raising
I was looking at http://bugs.winehq.org/show_bug.cgi?id=19861 and it seemed pretty easy to fix. In my opinion, the warning should either go in server/file.c - file_set_error() or in server/fd.c - open_fd(). open_fd() is pretty much the only place where open() is called, so it's a good candidate. On the other hand, having the check in file_set_error() might detect the condition in more instances, but it might also impact performance (file_set_error() is called really often; having lots of code in one branch might make the compiler generate slower code). The warning would go on the ENFILE/EMFILE branches, and maybe also print the value of getrlimit(RLIMIT_NOFILE) and suggest a fix (editing /etc/security/limits.conf). Octavian
Octavian Voicu <octavian.voicu(a)gmail.com> writes:
I was looking at http://bugs.winehq.org/show_bug.cgi?id=19861 and it seemed pretty easy to fix.
In my opinion, the warning should either go in server/file.c - file_set_error() or in server/fd.c - open_fd().
You can't print warnings from the server, they usually won't go where you want them to. -- Alexandre Julliard julliard(a)winehq.org
On Sun, May 9, 2010 at 8:23 PM, Alexandre Julliard <julliard(a)winehq.org> wrote:
You can't print warnings from the server, they usually won't go where you want them to.
That's unfortunate. The only remaining place to do that is in ntdll/FILE_CreateFile and check for status code STATUS_TOO_MANY_OPENED_FILES. We can't differentiate between ENFILE (the global open file limit was reached, given by fs.file-max sysctl) and EMFILE (RLIMIT_NOFILE was reached), but that wouldn't be a problem since ENFILE should be rare enough and there's also a KERN_INFO message to inform of that). Also, would it be ok to call getrlimit from ntdll, wrapped in a HAVE_SETRLIMIT ifdef (which is already used in libs/wine/loader.c)? Octavian
participants (2)
-
Alexandre Julliard -
Octavian Voicu