bug#22814: 25.0.91; Emacs runs out of file descriptors on OS X

[Michael Albinus <michael.albinus@gmx.de>]

Anders Lindgren <andlind@gmail.com> writes:

> Hi!

Hi Anders,

> I don't think the problem is what kqueue does when it run out of file
> descriptors, but how the rest of the Emacs process acts when this
> happens. For example, can it even read and write files? Can
> subprocesses be started?
>
> The question, then, is how should the kqueue system work so that it
> doesn't run Emacs out of file descriptors? For example, if it would be
> possible to check how many are available, it could stop when there
> are, say, 50 remaining. Effectively, this would give a user 200 files
> that are auto-reverted using the notification system, and the rest
> would be handled by the old timer system.

Something like this I plan to implement in kqueue.c and inotify.c. For
gfilenotify.c this shouldn't be necessary, it switches to polling
already when necessary. But maybe I retest.

Remote backends (inotifywait, gvfs-monitor-dir) are different, here it
isn't the number of file descriptors but the number of processes allowed
to start, which counts. I'll give it some thinking as well. Tramp is
written in Lisp, the checks will be harder to perform. Maybe I'll
introduce a hardcoded limit of possible file notification watches.

w32notify.c I cannot touch. Hopefully, somebody else takes the ball.

All of this shall go into the master, I believe. For the emacs-25 branch
we know what to do, described somewhere earlier in this bug's messages.

> -- Anders

Best regards, Michael.