From: Anders Lindgren <andlind@gmail.com>
To: Michael Albinus <michael.albinus@gmx.de>
Cc: 22814@debbugs.gnu.org
Subject: bug#22814: 25.0.91; Emacs runs out of file descriptors on OS X
Date: Sat, 27 Feb 2016 20:00:30 +0100 [thread overview]
Message-ID: <CABr8ebb3tLWLvm9t_atcPt0pTG_USfKp2H74Gr7OJymd_fDbtw@mail.gmail.com> (raw)
In-Reply-To: <87lh66nv22.fsf@gmx.de>
[-- Attachment #1: Type: text/plain, Size: 2524 bytes --]
Hi!
I just gave this some thought (without knowing anything about the kqueue
notifications).
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.
-- Anders
On Sat, Feb 27, 2016 at 2:26 PM, Michael Albinus <michael.albinus@gmx.de>
wrote:
> Eli Zaretskii <eliz@gnu.org> writes:
>
> >> > One simple way to handle this is to define a variable with "max"
> >> > number of files the notification system can handle. We can set this
> >> > to, say, 200 on OS X and unlimited on other systems.
> >>
> >> Would be possible, yes. I would prefer to set the limit to a system
> >> related value. Does there exist a portable way to detect, how many file
> >> descriptors / processes Emacs is able to consume?
> >
> > Not portably, AFAIK.
>
> On POSIX systems, we could propagate the result of
>
> if !(getrlimit (RLIMIT_NOFILE, &rlim))
> return make_number (rlim.rlim_cur);
> else
> return Qnil;
>
> Maybe we add a function like `<library>-max-descriptors' to the
> libraries. Or maybe not, and the backends check this themselves, and
> cease to work when reaching an internal limit. Such an internal limit
> could be half the number of soft RLIMIT_NOFILE on POSIX systems, for
> example.
>
> > Also, different implementations use different
> > resources for receiving file notifications. For example, w32notify
> > uses one handle and one thread per watched file/directory. The number
> > of handles a process can have on Windows is very large, and the
> > theoretical max number of threads is 32K, but both are limited by the
> > resources already consumed by the Emacs process. So determining the
> > practical maximum at any given point will require a non-trivial
> > function.
>
> There must be different scenarios for different file notification
> libraries. But using RLIMIT_NOFILE as basis when possible gives us
> better results on systems like OS X and FreeBSD, which both use kqueue,
> but provide different ressource limits.
>
> Best regards, Michael.
>
[-- Attachment #2: Type: text/html, Size: 3248 bytes --]
next prev parent reply other threads:[~2016-02-27 19:00 UTC|newest]
Thread overview: 53+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-26 6:18 bug#22814: 25.0.91; Emacs runs out of file descriptors on OS X David Caldwell
2016-02-26 8:34 ` Michael Albinus
2016-02-26 9:05 ` David Caldwell
2016-02-26 10:26 ` Nicolas Richard
2016-02-26 9:22 ` Eli Zaretskii
2016-02-26 20:05 ` Michael Albinus
2016-02-26 9:04 ` Eli Zaretskii
2016-02-26 20:51 ` Anders Lindgren
2016-02-27 8:00 ` Michael Albinus
2016-02-27 9:19 ` Eli Zaretskii
2016-02-27 13:26 ` Michael Albinus
2016-02-27 19:00 ` Anders Lindgren [this message]
2016-02-27 19:12 ` Michael Albinus
2016-02-27 19:17 ` Eli Zaretskii
2016-02-27 19:33 ` Michael Albinus
2016-02-27 19:39 ` Eli Zaretskii
2016-02-27 19:51 ` Michael Albinus
2016-02-27 19:58 ` Eli Zaretskii
2016-02-27 20:06 ` Michael Albinus
2016-02-27 20:25 ` Eli Zaretskii
2016-02-28 9:57 ` Michael Albinus
2016-02-28 15:51 ` Eli Zaretskii
2016-02-27 19:14 ` Eli Zaretskii
2016-02-27 19:26 ` Michael Albinus
2016-02-27 19:36 ` Eli Zaretskii
2016-02-27 19:39 ` Michael Albinus
2016-02-27 19:56 ` Michael Albinus
2016-02-27 20:06 ` Eli Zaretskii
2016-02-29 10:24 ` Michael Albinus
2016-02-29 16:02 ` Eli Zaretskii
2016-03-02 15:03 ` Michael Albinus
2016-03-02 16:01 ` Eli Zaretskii
2016-03-04 7:53 ` Michael Albinus
2016-03-04 8:14 ` John Wiegley
2016-03-04 8:29 ` Eli Zaretskii
2016-03-04 14:05 ` Michael Albinus
2016-03-04 14:11 ` Michael Albinus
2016-04-10 8:21 ` Michael Albinus
2016-04-10 20:37 ` Anders Lindgren
2016-04-11 6:40 ` Michael Albinus
2016-04-11 6:48 ` Anders Lindgren
2016-04-11 6:58 ` Michael Albinus
2016-04-11 18:59 ` Anders Lindgren
2016-04-12 7:44 ` Michael Albinus
2016-02-27 9:55 ` Anders Lindgren
2016-02-27 10:46 ` Eli Zaretskii
2016-02-27 11:38 ` Anders Lindgren
2016-02-27 12:17 ` Michael Albinus
2016-02-27 12:40 ` Eli Zaretskii
2016-02-27 12:49 ` Michael Albinus
2016-02-27 12:52 ` Eli Zaretskii
2016-02-27 13:00 ` Michael Albinus
2016-03-05 0:32 ` Paul Eggert
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CABr8ebb3tLWLvm9t_atcPt0pTG_USfKp2H74Gr7OJymd_fDbtw@mail.gmail.com \
--to=andlind@gmail.com \
--cc=22814@debbugs.gnu.org \
--cc=michael.albinus@gmx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.