From: Alexander Shukaev <emacs@alexander.shukaev.name>
To: emacs-devel@gnu.org
Cc: Emacs-devel <emacs-devel-bounces+emacs=alexander.shukaev.name@gnu.org>
Subject: Re: Emacs Hangs on Filesystem Operations on Stale NFS
Date: Mon, 11 Jun 2018 13:55:51 +0200 [thread overview]
Message-ID: <4daff1aff27be64eeb1c7bff45d86e0b@alexander.shukaev.name> (raw)
In-Reply-To: <1727545582523435cab149c2bc857b40@alexander.shukaev.name>
On 2018-06-11 12:27, Alexander Shukaev wrote:
> Hi Everyone,
>
>
> I initiated a discussion back in 2015 [1] about fragility of Emacs in
> terms of filesystem operations on stale NFS. No solution actually
> came out of this discussion. I still find this issue very disruptive.
> Yet another example would be `recentf-cleanup' which is in my case
> triggered on Emacs start up, when the file comes from stale NFS, the
> corresponding `file-readable-p' down the stack will hang indefinitely,
> and there would be no way to unfreeze it apart from issuing 'kill -9'
> to that Emacs instance. Don't you people find it unacceptable for the
> daily usage? Well, I do. Such hangs always disrupt daily work and
> require quite some time to track them down as they are not
> Lisp-debuggable with e.g. <C-g> in a straightforward way (these are
> dead hangs from C code, where even attaching a GDB does not work).
>
> Well, enough rant. I think I have a proposal how to fix the issue,
> even given the blocking nature of Emacs. How about introducing a
> variable `file-access-timeout' defaulting to `nil', which would
> reflect a configurable timeout for all access operations (such as
> `file-readable-p')? This would be achieved via `SIGALARM' in the C
> code, which would protect every such operation. For example,
>
> #include <sigaction.h>
> #include <sys/stat.h>
> #include <unistd.h>
> #include <string.h>
>
> static void alarm_handler(int sig)
> {
> return;
> }
>
> int emacs_stat(const char* path, struct stat* s, unsigned int seconds)
> {
> struct sigaction newact;
> struct sigaction oldact;
>
> memset(&newact, 0, sizeof(newact));
> memset(&oldact, 0, sizeof(oldact));
>
> sigemptyset(&newact.sa_mask);
>
> newact.sa_flags = 0;
> newact.sa_handler = alarm_handler;
> sigaction(SIGALRM, &newact, &oldact);
>
> alarm(seconds);
>
> errno = 0;
> const int rc = stat(path, s);
> const int saved_errno = errno;
>
> alarm(0);
> sigaction(SIGALRM, &oldact, NULL);
>
> errno = saved_errno;
> return rc;
> }
>
> where `seconds' should be initialized with the value of
> `file-access-timeout'. The cool advantage of this that I see is that
> one can then also selectively `let'-bind different values for
> `file-access-timeout', thus having total control over the use cases in
> which one wants to protect oneself from indefinite hangs.
>
> Kind regards,
> Alexander
>
> [1]
> https://lists.gnu.org/archive/html/help-gnu-emacs/2015-11/msg00251.html
A couple of more ideas:
- I think it is reasonable to actually signal a dedicated error in case
of the timeout so that API consumers can handle it accordingly to their
needs.
- It might be worth to also factor this alarm mechanism out into a
separate macro, e.g. similar to `condition-case', where one could wrap a
piece of Lisp code into that macro by supplying a timeout and expect it
to call a timeout handler code in case of timeout:
(with-system-timeout 3
(do-something)
(message "%s" "Timed out after 3 seconds..."))
This would also give Lisp developers full control over system related
interactions.
Regards,
Alexander
next prev parent reply other threads:[~2018-06-11 11:55 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-06-11 10:27 Emacs Hangs on Filesystem Operations on Stale NFS Alexander Shukaev
2018-06-11 11:01 ` Andreas Schwab
2018-06-11 11:05 ` Alexander Shukaev
2018-06-11 11:50 ` Andreas Schwab
2018-06-11 12:03 ` Alexander Shukaev
2018-06-11 11:55 ` Alexander Shukaev [this message]
2018-06-11 11:59 ` Noam Postavsky
2018-06-11 12:11 ` Alexander Shukaev
2018-06-11 12:20 ` Noam Postavsky
2018-06-11 12:22 ` Alexander Shukaev
2018-06-11 12:34 ` Noam Postavsky
2018-06-11 12:41 ` Alexander Shukaev
2018-06-11 12:40 ` Andreas Schwab
2018-06-11 12:46 ` Alexander Shukaev
2018-06-11 15:51 ` Eli Zaretskii
2018-06-13 15:40 ` Paul Eggert
2018-06-12 17:26 ` Davis Herring
2018-06-12 18:26 ` Perry E. Metzger
2018-06-11 15:04 ` Stefan Monnier
2018-06-11 16:46 ` Mike Kupfer
2018-06-11 17:08 ` Stefan Monnier
2018-06-13 10:45 ` Alexander Shukaev
2018-06-13 12:35 ` Yuri Khan
2018-06-13 14:23 ` Stefan Monnier
2018-06-13 15:30 ` Yuri Khan
2018-06-13 18:09 ` Michael Albinus
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
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4daff1aff27be64eeb1c7bff45d86e0b@alexander.shukaev.name \
--to=emacs@alexander.shukaev.name \
--cc=emacs-devel-bounces+emacs=alexander.shukaev.name@gnu.org \
--cc=emacs-devel@gnu.org \
/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 public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).