From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: mituharu@math.s.chiba-u.ac.jp Newsgroups: gmane.emacs.bugs Subject: bug#28630: 27.0.50; C-g while a non-main thread is sitting crashes Emacs Date: Mon, 9 Oct 2017 19:34:28 +0900 Message-ID: References: <87efqri8x9.fsf@gmail.com> <874lrjy2rz.fsf@gmail.com> <831smm52v4.fsf@gnu.org> <87d166rb6n.fsf@gmail.com> <83o9pq3eix.fsf@gnu.org> <838tgt352c.fsf@gnu.org> <83fuazz7ja.fsf@gnu.org> <83a817z5sd.fsf@gnu.org> <834lrfz2pk.fsf@gnu.org> <83infuxdk4.fsf@gnu.org> <838tgksol2.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain;charset=iso-2022-jp Content-Transfer-Encoding: 8bit X-Trace: blaine.gmane.org 1507545319 17513 195.159.176.226 (9 Oct 2017 10:35:19 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 9 Oct 2017 10:35:19 +0000 (UTC) User-Agent: SquirrelMail/1.4.22-5.el6 Cc: 28630@debbugs.gnu.org, tom@tromey.com, agrambot@gmail.com To: "Eli Zaretskii" Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Oct 09 12:35:11 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 1e1VOt-0002sg-2g for geb-bug-gnu-emacs@m.gmane.org; Mon, 09 Oct 2017 12:35:07 +0200 Original-Received: from localhost ([::1]:57048 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1e1VOy-0006Yk-Tv for geb-bug-gnu-emacs@m.gmane.org; Mon, 09 Oct 2017 06:35:12 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:46664) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1e1VOr-0006Y2-U9 for bug-gnu-emacs@gnu.org; Mon, 09 Oct 2017 06:35:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1e1VOn-0007PD-V9 for bug-gnu-emacs@gnu.org; Mon, 09 Oct 2017 06:35:05 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:48483) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1e1VOn-0007Ow-S3 for bug-gnu-emacs@gnu.org; Mon, 09 Oct 2017 06:35:01 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1e1VOn-0002q2-MS for bug-gnu-emacs@gnu.org; Mon, 09 Oct 2017 06:35:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: mituharu@math.s.chiba-u.ac.jp Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 09 Oct 2017 10:35:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 28630 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 28630-submit@debbugs.gnu.org id=B28630.150754527510866 (code B ref 28630); Mon, 09 Oct 2017 10:35:01 +0000 Original-Received: (at 28630) by debbugs.gnu.org; 9 Oct 2017 10:34:35 +0000 Original-Received: from localhost ([127.0.0.1]:57164 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1e1VON-0002pC-Es for submit@debbugs.gnu.org; Mon, 09 Oct 2017 06:34:35 -0400 Original-Received: from mathmail.math.s.chiba-u.ac.jp ([133.82.132.2]:61277) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1e1VOJ-0002p0-GC for 28630@debbugs.gnu.org; Mon, 09 Oct 2017 06:34:32 -0400 Original-Received: from weber.math.s.chiba-u.ac.jp (weber [192.168.32.4]) by mathmail.math.s.chiba-u.ac.jp (Postfix) with ESMTP id AB7E1F08E5; Mon, 9 Oct 2017 19:34:28 +0900 (JST) (envelope-from mituharu@math.s.chiba-u.ac.jp) Original-Received: from 114.157.130.169 (SquirrelMail authenticated user mituharu) by weber.math.s.chiba-u.ac.jp with HTTP; Mon, 9 Oct 2017 19:34:28 +0900 In-Reply-To: <838tgksol2.fsf@gnu.org> X-Priority: 3 (Normal) Importance: Normal 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:138109 Archived-At: >> In principle, the method I used for the Mac port is also applicable to >> X11 (but probably not for NS where secondary threads cannot read >> keyboard input). Each pselect call not involving keyboard input >> additionally monitors one side of a socket pair, and the SIGALRM >> handler writes to the other side. This way, a pselect call in a >> secondary thread is unblocked when the signal arrived, and then it >> tries to see if keyboard input is available when none of other threads >> is monitoring the keyboard input channel. > > But the problematic part in these examples is that the main thread > always waits for keyboard input, because the non-main thread starts > running only when the main thread becomes idle, and becoming idle > means calling pselect. And since the main thread is always the first > one to call pselect, it is the thread which finds the keyboard > descriptor unmonitored, and installs itself as its monitoring thread. > > So with your proposal, more often than not, the "none of other threads > is monitoring the keyboard input channel" part will never be true, > except for the main thread. Or am I missing something? In both Examples, the main thread is not blocking at pselect, but thread-join (sys_cond_wait internally), i.e., without monitoring the keyboard descriptor. The secondary one is blocking at pselect in sit-for (Example 1) or sleep-for (Example 2). So "none of other threads is monitoring the keyboard input channel" part becomes true for the secondary thread after returning from pselect. In Example 2, no thread is monitoring the keyboard while the secondary thread is blocking at pselect, and that is why the Mac port could not be interrupted with C-g previously. I think this basically also applies to X11. For GTK+ cases, my guess is the additionally monitored descriptors obtained by g_main_context_query has something to do with its peculiar behavior. YAMAMOTO Mitsuharu mituharu@math.s.chiba-u.ac.jp