From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Richard Copley Newsgroups: gmane.emacs.bugs Subject: bug#25875: 26.0.50; Hang logging out of MS-Windows Date: Mon, 27 Feb 2017 20:52:16 +0000 Message-ID: References: <83lgsuqacv.fsf@gnu.org> <83efylq7m4.fsf@gnu.org> <834lzgreqq.fsf@gnu.org> <3f07808e-ab1c-d6b5-9ea0-dfc4c6fd6fc9@cornell.edu> <8337f0rbz6.fsf@gnu.org> <83shmzprwo.fsf@gnu.org> <83fuizphp8.fsf@gnu.org> <83efyjpef6.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 X-Trace: blaine.gmane.org 1488229157 9242 195.159.176.226 (27 Feb 2017 20:59:17 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 27 Feb 2017 20:59:17 +0000 (UTC) Cc: 25875@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Feb 27 21:59:12 2017 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ciSNx-0001jq-Rc for geb-bug-gnu-emacs@m.gmane.org; Mon, 27 Feb 2017 21:59:10 +0100 Original-Received: from localhost ([::1]:56795 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ciSO3-0000Dh-S5 for geb-bug-gnu-emacs@m.gmane.org; Mon, 27 Feb 2017 15:59:15 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:38725) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ciSI6-0003Wo-H4 for bug-gnu-emacs@gnu.org; Mon, 27 Feb 2017 15:53:07 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ciSI2-0006u5-Kw for bug-gnu-emacs@gnu.org; Mon, 27 Feb 2017 15:53:06 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:60535) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1ciSI2-0006u1-Gi for bug-gnu-emacs@gnu.org; Mon, 27 Feb 2017 15:53:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1ciSI2-0008Fj-A1 for bug-gnu-emacs@gnu.org; Mon, 27 Feb 2017 15:53:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Richard Copley Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 27 Feb 2017 20:53:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 25875 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 25875-submit@debbugs.gnu.org id=B25875.148822877531710 (code B ref 25875); Mon, 27 Feb 2017 20:53:02 +0000 Original-Received: (at 25875) by debbugs.gnu.org; 27 Feb 2017 20:52:55 +0000 Original-Received: from localhost ([127.0.0.1]:58734 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ciSHv-0008FO-7Z for submit@debbugs.gnu.org; Mon, 27 Feb 2017 15:52:55 -0500 Original-Received: from mail-ua0-f182.google.com ([209.85.217.182]:34151) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ciSHt-0008FA-3d for 25875@debbugs.gnu.org; Mon, 27 Feb 2017 15:52:53 -0500 Original-Received: by mail-ua0-f182.google.com with SMTP id f54so40013091uaa.1 for <25875@debbugs.gnu.org>; Mon, 27 Feb 2017 12:52:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=NcBOE9i1kFjNTZvdZEb2nFmUeOwduwis/cdngeXvVB8=; b=OzatRdZxd4golWaP7MfVWNyvumHCikF9OEq37NmBoAHivtPuREpKEyfMhuGnBEcE8o oHYEXpAU1SykxUpefvlfIznq6k+pP2D5nU5jT/pEv2h4JvYZjJ9uGOazcpwwfcXc8tA/ 8mPRDsYm8fu5Irj6zLTHmj/f5rJUoBpCuy7cMSK56sb27UAzvkcxtqGS+OQ0GVOAvgyj okBZoFDg4Qmdd/p3j9uyaz6bJ/wq4gzT4LwfC/87zZXphMEFjjPcAGNx5JWuLD6oPuhh 098Goxk4YSTDKro6YIhoWFVu0m/1XN4pFXqxLsf3zLGgxYQZE2LXqX62KFgywBPlSQZI Aa2g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=NcBOE9i1kFjNTZvdZEb2nFmUeOwduwis/cdngeXvVB8=; b=jqmzfMPsLwbCZojH20Qn7E2mEJ7kOoguGFnT7BLsivvvL8WfjAQkUWsl6YkjqljUam 1+yr4X1952xB1txY7ucIrLMHL3ui9yDzzEPzBG5OaG4CDe0u4IZueP5GhFyIZvMpnWeN WOJXcOeAGz97indz4qcv5f8g/2NzeIAkLzbKt7IeH/iBAFriGOcJJLpU6QpiHaeMEueE l/KzCzBU+a5R8IK3Ya8pFhxlUCiVB4lP4chykNvxx3WfBtd98B9L8Y50LzkwxYzy9pDW mYxzE6HA7Nwuppme2vNmmwcKTFrxHaJxT6JvzNyuGsYBTsNpjwpQlQqx0dIqyUrmfczb NAPw== X-Gm-Message-State: AMke39ma3bJ+dHHsm3Am2sXF3R/HVK50JPtxSyGAB1ejD3ovN/MeQyBAUZCDRr5SGBXaDz3iCWLSyYGGviFZeA== X-Received: by 10.31.248.142 with SMTP id w136mr7646286vkh.140.1488228767385; Mon, 27 Feb 2017 12:52:47 -0800 (PST) Original-Received: by 10.176.71.214 with HTTP; Mon, 27 Feb 2017 12:52:16 -0800 (PST) In-Reply-To: <83efyjpef6.fsf@gnu.org> 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" Xref: news.gmane.org gmane.emacs.bugs:129907 Archived-At: On 27 February 2017 at 20:27, Eli Zaretskii wrote: >> From: Richard Copley >> Date: Mon, 27 Feb 2017 19:46:21 +0000 >> Cc: Eli Zaretskii , 25875@debbugs.gnu.org >> >> > Bug#23483. >> >> That's not a real issue, in my opinion. It's already covered, >> by autosave. > > I don't think it is, because when WM_ENDSESSION comes in, Emacs will > be terminated without giving it a chance to auto-save. > > Ken's change was meant to delay the shutdown long enough for Emacs to > exit in an orderly fashion. The idea of the design is correct, IMO, > it's just that we should avoid the hang. OK. I don't mean to be difficult, I just don't see what testing I can do that would be of any use. Eli, you said: > As I understand it, this happens because when the input thread gets > the WM_ENDSESSION message, it posts it to the main thread and goes on > to sleep for 1000 sec, to avoid ending the Emacs process before it > finishes orderly shutdown. But if the main thread happens to be > inside redisplay, it could invoke one of the function that send > messages to the input thread via SendMessage, which waits for the > input thread to respond. So we do have a kind of deadlock. Posting a message and then sleeping while it's processed is odd, isn't it? If the input thread /sent/ its message to the main thread, then while waiting for SendMessage to return, the input thread would automatically continue to process sent messages