GNU bug report logs - #22814
25.0.91; Emacs runs out of file descriptors on OS X

Previous Next

Full log

View this message in rfc822 format

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Anders Lindgren <andlind <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 22814 <at> debbugs.gnu.org
Subject: bug#22814: 25.0.91; Emacs runs out of file descriptors on OS X
Date: Sat, 27 Feb 2016 20:12:18 +0100

Anders Lindgren <andlind <at> 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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.