From: Eli Zaretskii <eliz@gnu.org>
To: Alexander Shukaev <emacs@alexander.shukaev.name>
Cc: schwab@suse.de,
emacs-devel-bounces+emacs=alexander.shukaev.name@gnu.org,
npostavs@gmail.com, emacs-devel@gnu.org
Subject: Re: Emacs Hangs on Filesystem Operations on Stale NFS
Date: Mon, 11 Jun 2018 18:51:43 +0300 [thread overview]
Message-ID: <83efhdqq28.fsf@gnu.org> (raw)
In-Reply-To: <aa8bc66ebf71515e96e2e1adea170308@alexander.shukaev.name> (message from Alexander Shukaev on Mon, 11 Jun 2018 14:46:35 +0200)
> Date: Mon, 11 Jun 2018 14:46:35 +0200
> From: Alexander Shukaev <emacs@alexander.shukaev.name>
> Cc: Emacs-devel <emacs-devel-bounces+emacs=alexander.shukaev.name@gnu.org>,
> Noam Postavsky <npostavs@gmail.com>, Emacs developers <emacs-devel@gnu.org>
>
> On 2018-06-11 14:40, Andreas Schwab wrote:
> > On Jun 11 2018, Alexander Shukaev <emacs@alexander.shukaev.name> wrote:
> >
> >> signal.signal(signal.SIGALRM, alarm_handler)
> >> signal.alarm(3)
> >> try:
> >> proc = subprocess.call('stat ' + path,
> >> shell=True,
> >> stderr=subprocess.PIPE,
> >> stdout=subprocess.PIPE)
> >> stdoutdata, stderrdata = proc.communicate()
> >> signal.alarm(0)
> >> except Alarm:
> >> print "Timed out after 3 seconds..."
> >
> > How do you know that 3 seconds is enough?
> >
> > Andreas.
>
> You don't know. You just decide that it's maximum tolerable for
> you/your setup/hardware/connection/preferences/whatever, otherwise you
> are 99.(9)% sure that something is wrong somewhere with your system, but
> you don't give up your Emacs instance for that and rather get indicated
> that there might be a potential problem.
I think there's more here than meets the eye. Sure, it's quite easy
to come up with a toy program that uses SIGALRM to time out a system
call that went awry. But Emacs is not a toy program, so doing that
has complications, even if we will come up with a suitable number of
seconds to wait (which ain't easy, since some I/O calls could really
need a long time, or example reading a large file or directory).
Here are some complications we should keep in mind:
. Emacs already uses SIGALRM for different purposes, see atimer.c.
Reusing it for this issue will need some complex logic, to avoid
breaking the features that use SIGALRM now.
. You tried this with a single 'stat' call, but that's just the tip
of the iceberg. Typically, Emacs will need to read a file after
it found it readable, and we normally do that in a way that keeps
looping as long as the system call was interrupted by signals, see,
e.g., emacs_intr_read. Then setting up an alarm clock will not
help if 'read' hangs, we will just loop forever.
. We usually deliver signals to the main thread, so if the code that
hangs happens to run in a non-main thread (recall that Emacs 26
has threads), it will be somewhat tricky, to say the least, to
deliver signal there.
. Even if we somehow succeed to interrupt the hang by a signal, it's
not clear whether it's safe to continue running the session --
there's a reason why we stopped doing non-trivial stuff in signal
handlers. It may be that the only sensible thing is to shut down,
and in that case, what did we gain, exactly?
. This technique is non-portable to MS-Windows.
There are probably other complications.
All in all, I'd be much happier if we could interrupt such hangs,
e.g. by C-g, as Stefan points out (on a TTY frame, this should already
be possible in many cases, since C-g there generates SIGINT). But I'm
not sure this would be possible in general. Maybe Paul will have some
ideas.
next prev parent reply other threads:[~2018-06-11 15:51 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
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 [this message]
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=83efhdqq28.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=emacs-devel-bounces+emacs=alexander.shukaev.name@gnu.org \
--cc=emacs-devel@gnu.org \
--cc=emacs@alexander.shukaev.name \
--cc=npostavs@gmail.com \
--cc=schwab@suse.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 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).