From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Michael Albinus Newsgroups: gmane.emacs.bugs Subject: bug#22814: 25.0.91; Emacs runs out of file descriptors on OS X Date: Sat, 27 Feb 2016 14:26:29 +0100 Message-ID: <87lh66nv22.fsf@gmx.de> References: <87twkupoq9.fsf@gmx.de> <83d1ricxyp.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1456579645 16339 80.91.229.3 (27 Feb 2016 13:27:25 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 27 Feb 2016 13:27:25 +0000 (UTC) Cc: 22814@debbugs.gnu.org, andlind@gmail.com To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Feb 27 14:27:10 2016 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1aZetp-0007V8-LO for geb-bug-gnu-emacs@m.gmane.org; Sat, 27 Feb 2016 14:27:09 +0100 Original-Received: from localhost ([::1]:54881 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aZeto-0001g7-Uz for geb-bug-gnu-emacs@m.gmane.org; Sat, 27 Feb 2016 08:27:08 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:33514) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aZetl-0001fw-Ah for bug-gnu-emacs@gnu.org; Sat, 27 Feb 2016 08:27:06 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aZeti-0007O0-58 for bug-gnu-emacs@gnu.org; Sat, 27 Feb 2016 08:27:05 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:51156) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aZeti-0007Nw-1c for bug-gnu-emacs@gnu.org; Sat, 27 Feb 2016 08:27:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84) (envelope-from ) id 1aZeth-000436-OR for bug-gnu-emacs@gnu.org; Sat, 27 Feb 2016 08:27:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Michael Albinus Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 27 Feb 2016 13:27:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 22814 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 22814-submit@debbugs.gnu.org id=B22814.145657959915536 (code B ref 22814); Sat, 27 Feb 2016 13:27:01 +0000 Original-Received: (at 22814) by debbugs.gnu.org; 27 Feb 2016 13:26:39 +0000 Original-Received: from localhost ([127.0.0.1]:48283 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aZetL-00042W-33 for submit@debbugs.gnu.org; Sat, 27 Feb 2016 08:26:39 -0500 Original-Received: from mout.gmx.net ([212.227.17.22]:63506) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aZetJ-00042K-LB for 22814@debbugs.gnu.org; Sat, 27 Feb 2016 08:26:38 -0500 Original-Received: from detlef.gmx.de ([93.209.85.192]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0Lb90f-1aB1WY02Zd-00keN2; Sat, 27 Feb 2016 14:26:31 +0100 In-Reply-To: <83d1ricxyp.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 27 Feb 2016 11:19:10 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (gnu/linux) X-Provags-ID: V03:K0:oUZvLYQJ5QyQRRHQMxpPl8EeJxXxO6swtDvySWGmPS+z4KuzPg1 ORteduCVNspA5IT6N+RNzj3gXrole2SBNoLEl1lyi9O7u4kbXSgLEUNtQavjLwrMYP/IDwo XF5ifGMdiTUU+z/XYuwpL1aMUPN+HeisQGJ9tsJ5ROeOCqi2at1xCl8XoEDd5iJmjMLetJk /KilGmUGFIIP1p6WLm5nQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:uUkSuYQ3LI8=:uawOPHhdc2g5c+JOjiA5/L eccY5pp66ttJm6MObxWRkZYxYU7aMXMlw7833fGW3Rtz5vIDVqrCmb2c2IK6nsygee1+WtdXb I2sVLnqqeTPeI7YpIta1+qnVaKQL5Rm4hw38XAxPgOdpM6VTdhEqDnhZWuE+ZymjAEjFbxhTN 4N/MTB3IiQLl7x6HZjhevMRmmDaKnAZ+9q6LsJry7DwBw1jJLjs+8fVu/tQjfwIagFACnmWWc juaFLQXQhsC+gLB46guPLJ4zPJLyoYxk6eE2inb+5TsN+GD2fv0vcAQ4PvJF1uMkKmy+SNH3k 9bdt1e0OA9gXUqgmqCPMaq8iIw2wfeQwkT/g6IbvPOa+WVBBCMjgU6m4jCzOxtdTKPAL+CClO /nxuAfOCWftppi+4V8eJ8afHrr53tzD/YL2o/bXzrrfXiILYwxGnsppiKnK0LRt4RjuVlttHU JIs2LwXyRwukP8UpOrCRQ8sE3FbAc+qBsdbs6stpISb7PSN8Y1s0PGwk6RQBWFLIFt536Wbzp 8S94WzpmSThXZwFZYc/f4j5xM1wf7j1MS7R5AP4cqoZSSJAcJ/iqq286tjkRZoS4YZrmeDQ9Y k1+vGRRYQZqPFrtO3+CpMKqJm61/usDHv8z2QHt5+RXTJOuBTZyWbmVmAycWlfFuiXtPxp3TX rT76H/VQqXsMpdUG/H0jqLEjUVOv3YWzEeUZSVxmb9JzG7+r5o3Pe/Wu9FxSZc8Wl4VruoDCn t3oesXwLDxN/8II2pp0aFyoE48/sXFVIGxrAvrXR9y6Hs34a13eyehLGLuax+5EMA7Z3YX4g X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:113951 Archived-At: Eli Zaretskii 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 `-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.