|
From: | Davis Herring |
Subject: | Re: Emacs Hangs on Filesystem Operations on Stale NFS |
Date: | Tue, 12 Jun 2018 11:26:55 -0600 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.0 |
signal.alarm(3)try: proc = subprocess.call('stat ' + path,shell=True, stderr=subprocess.PIPE, stdout=subprocess.PIPE)
You're sending SIGALRM to the _parent_, not the (possibly-frozen) stat(1) child. Of course that works; you're just interrupting normal pipe I/O with (or wait(2) on) the child.
Emacs can't possibly do all of its file operations in subprocesses. A complete redesign might allow the "process per tab" model used in some modern browsers, but that would break much of existing Lisp. It might just be possible to have a "file server process" that could be killed and reincarnated as needed, but I wouldn't want to promise much about performance (and support for concurrent I/O).
Incidentally, don't mix call() and communicate(), and avoid "shell=True", especially when the replacement is easier:
proc = subprocess.Popen(['stat', path], stderr=subprocess.PIPE, stdout=subprocess.PIPE) [From a later message:]
There are plenty of other ways why those file operations might hang. For example, [1]. [1] http://unix.stackexchange.com/questions/63071/local-regular-file-causes-stat-or-ls-l-to-hang
The (single, accepted) answer there says that it was an LDAP issue looking up user/group names. That's not a file operation at all.
Davis --This product is sold by volume, not by mass. If it appears too dense or too sparse, it is because mass-energy conversion has occurred during shipping.
[Prev in Thread] | Current Thread | [Next in Thread] |