Wine should warn when ulimit -n needs raising

[Octavian Voicu]

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

[Alexandre Julliard]

Octavian Voicu  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.

[Octavian Voicu]

On Sun, May 9, 2010 at 8:23 PM, Alexandre Julliard  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