From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.help Subject: Re: It's almost 2016 and when (single-threaded) Emacs hangs, you gotta be smashing your keyboard! Date: Thu, 19 Nov 2015 23:09:47 +0200 Message-ID: <83si417l2c.fsf@gnu.org> References: <83vb8x7m5a.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1447967438 24327 80.91.229.3 (19 Nov 2015 21:10:38 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 19 Nov 2015 21:10:38 +0000 (UTC) To: help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Thu Nov 19 22:10:30 2015 Return-path: Envelope-to: geh-help-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 1ZzWTK-0005eJ-Ug for geh-help-gnu-emacs@m.gmane.org; Thu, 19 Nov 2015 22:10:27 +0100 Original-Received: from localhost ([::1]:44062 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZzWTK-0003jS-Ec for geh-help-gnu-emacs@m.gmane.org; Thu, 19 Nov 2015 16:10:26 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:53463) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZzWT3-0003Xr-DG for help-gnu-emacs@gnu.org; Thu, 19 Nov 2015 16:10:13 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZzWSz-0002dO-6q for help-gnu-emacs@gnu.org; Thu, 19 Nov 2015 16:10:09 -0500 Original-Received: from mtaout22.012.net.il ([80.179.55.172]:56972) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZzWSy-0002bc-V9 for help-gnu-emacs@gnu.org; Thu, 19 Nov 2015 16:10:05 -0500 Original-Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0NY200300YNU0U00@a-mtaout22.012.net.il> for help-gnu-emacs@gnu.org; Thu, 19 Nov 2015 23:10:02 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([84.94.185.246]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NY20024IYSPFQ90@a-mtaout22.012.net.il> for help-gnu-emacs@gnu.org; Thu, 19 Nov 2015 23:10:02 +0200 (IST) In-reply-to: X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 X-Received-From: 80.179.55.172 X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Original-Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.help:108146 Archived-At: > Date: Thu, 19 Nov 2015 21:55:06 +0100 > From: Alexander Shukaev > Cc: help-gnu-emacs > > > FWIW, it isn't unreliable or fragile for me. It is rather rock-solid, > > my sessions are usually open for many weeks on end, and almost never > > crash or hang. > > Exactly, "almost never", but hangs DO happen. Not here. I have crashes maybe once or twice a year, that's all. No hangs. > >> It may freeze or it may not freeze, but if it does, all of the > >> unsaved work is lost, not to mention the fact that all of the layout > >> of windows and open buffers are lost as well. > > > > Neither of this is true. When Emacs hits a fatal error, it > > auto-saves, and if you activate the desktop-saving feature, it will > > save a snapshot of your window and frame configuration fairly > > frequently, so starting a new session recreates at least those buffers > > which were visiting files or directories. > > Could you please provide concrete settings for this? Desktop saving is in the manual, see the node "Saving Emacs Sessions". Auto-saving on fatal errors happens by default, but you should select the signal you use to kill Emacs wisely: e.g., "kill -9" is usually a bad idea. > Also, maybe it does save on fatal error, but you have no chance of > saving upon killing the Emacs process due to dead hang. Signals that can be caught are treated the same as fatal errors. Emacs catches them all, and auto-saves before committing suicide. You can also bind commands to SIGUSR1 and SIGUSR2 events, you will find documentation and example in the "Misc Events" node of the ELisp manual. Then you can "kill -USR1 emacs-PID", and have it auto-save, or maybe call 'error' to get to top level. > >> First of all, I just want to once again draw your attention to one > >> of the urgent issues (to this date) of Emacs. > > > > Which urgent issue is that? > > The one described above: dead handing. AFAIR, you are the first who thinks this happens frequently enough to be a serious issue. Unless you are using development snapshots, where all bets are off. (I was talking about official releases.) But anyway, in every such case attaching the debugger to Emacs and reporting a bug with the details about where it hangs, or at least providing a recipe and any information regarding the hang you can come up with, is the only efficient way to make the situation better. Complaining here certainly won't cut it. > >> And, secondly, I want to ask whether there exists a way to solve the > >> problem described above without multi-threading? > > > > On Posix systems, Emacs does use a kind of multi-threading: it invokes > > the 'ls' command to generate the directory listing. You can configure > > Emacs on Windows to do the same, if you can get your hands on a decent > > port of GNU 'ls'. > > > > I'm using 'ls' on both Linux and Windows and this does not prevent the > occasional hang on network directories. But then it's 'ls' that's hanging, not Emacs, right? Emacs just waits for 'ls', and it should be relatively easy to interrupt the wait, either by "C-g" or by sending a signal, see above.