From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#25265: make-thread crashes in OS X 10.6 Date: Thu, 29 Dec 2016 19:12:54 +0200 Message-ID: <83vau2u0a1.fsf@gnu.org> References: <83r34xxlke.fsf@gnu.org> <83d1ggxayi.fsf@gnu.org> <20161226130917.GA36471@breton.holly.idiocy.org> <8337hay9fl.fsf@gnu.org> <20161226205632.GA36805@breton.holly.idiocy.org> <83k2alx20b.fsf@gnu.org> <20161227104424.GA45039@breton.holly.idiocy.org> <83bmvxwrp4.fsf@gnu.org> <20161228193633.GA47290@breton.holly.idiocy.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: blaine.gmane.org 1483031658 6595 195.159.176.226 (29 Dec 2016 17:14:18 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 29 Dec 2016 17:14:18 +0000 (UTC) Cc: charles@aurox.ch, 25265@debbugs.gnu.org To: Alan Third Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu Dec 29 18:14:13 2016 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 1cMeHG-0000Zz-Vn for geb-bug-gnu-emacs@m.gmane.org; Thu, 29 Dec 2016 18:14:07 +0100 Original-Received: from localhost ([::1]:36576 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cMeHL-0008SE-QN for geb-bug-gnu-emacs@m.gmane.org; Thu, 29 Dec 2016 12:14:11 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:35119) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cMeHF-0008S5-PO for bug-gnu-emacs@gnu.org; Thu, 29 Dec 2016 12:14:06 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cMeHC-0004sD-JP for bug-gnu-emacs@gnu.org; Thu, 29 Dec 2016 12:14:05 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:43912) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1cMeHC-0004s9-Fd for bug-gnu-emacs@gnu.org; Thu, 29 Dec 2016 12:14:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1cMeHB-0007Tc-OY for bug-gnu-emacs@gnu.org; Thu, 29 Dec 2016 12:14:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 29 Dec 2016 17:14:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 25265 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 25265-submit@debbugs.gnu.org id=B25265.148303159028673 (code B ref 25265); Thu, 29 Dec 2016 17:14:01 +0000 Original-Received: (at 25265) by debbugs.gnu.org; 29 Dec 2016 17:13:10 +0000 Original-Received: from localhost ([127.0.0.1]:59311 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cMeGM-0007SO-17 for submit@debbugs.gnu.org; Thu, 29 Dec 2016 12:13:10 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:43922) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cMeGK-0007SB-I1 for 25265@debbugs.gnu.org; Thu, 29 Dec 2016 12:13:08 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cMeGC-0004jc-2G for 25265@debbugs.gnu.org; Thu, 29 Dec 2016 12:13:03 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:55784) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cMeGB-0004jY-Ue; Thu, 29 Dec 2016 12:12:59 -0500 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:1318 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1cMeGB-0002sy-5V; Thu, 29 Dec 2016 12:12:59 -0500 In-reply-to: <20161228193633.GA47290@breton.holly.idiocy.org> (message from Alan Third on Wed, 28 Dec 2016 19:36:33 +0000) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] 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:127553 Archived-At: > Date: Wed, 28 Dec 2016 19:36:33 +0000 > From: Alan Third > Cc: charles@aurox.ch, 25265@debbugs.gnu.org > > > That's probably the only reasonable way. But why does it use > > record_unwind_protect and unbind_to in the first place? What happens > > if the user presses C-g while the event loop runs? > > It was added in change 08f27aa39c498d34418c7420b33bf2db913827c3 which > relates to bug 18345. Previously it was simply apploopnr--, but > sometimes users would find themselves in a situation where that line > was never run (hitting C‐g while the event loop runs?) so the next > time ns_select (or ns_read_socket) ran it aborted. I take it unbind_to > fixes that particular problem. > > Is there a safer way of ensuring that apploopnr is decremented? There could be, but I see that ns_select and ns_read_socket use it for some kind of synchronization between them, which I don't really understand, so I cannot answer that question. > I’m slowly beginning to understand what’s going on in ns_select. It > seems the idea is that it should detect both input on file descriptors > (using pselect in the background), and NS events coming from [NSApp > run]. What do "NS events" include? Do they include, for example, keyboard input? Also, does C-g cause a signal or some other async event on NS, which could potentially interrupt the [NSApp run] stuff? Or could SIGIO do that (does NS use SIGIO for input?)? If nothing could interrupt/QUIT [NSApp run], then I don't really understand why we have unwind_protect there. The bug in question cites some undisclosed Lisp for reproducing the problem, so I wonder how could that cause [NSApp run] to be interrupted and longjmp to higher level. > There is another thread that runs in a loop (fd_handler), and when > it’s signalled from ns_select, it runs pselect. At the same time > ns_select sets up a timer, then it calls [NSApp run]. (I think ns_select only sets up a timer when there are no descriptors to watch, to avoid waking up the fd_handler thread in that case.) So this means there are 2 jobs to be done here: the pselect call and the [NSApp run] call. > If either the pselect thread, or the timer run out before any input is > detected, they send a user defined event to the NSApp event loop so it > ends. > > Similarly if the pselect thread detects input it sends an event to the > NSApp loop, which then ends. > > If there’s NS input, it’s processed by the NSApp loop Processed how? Shouldn't Emacs be involved in this processing? IOW, these events should be read by Emacs, via the read_socket_hook. > Whatever happens, the NSApp loop eventually returns control back to > ns_select, which works out what happened by examining the last NS > event and returns the relevant value. > > I have my doubts this is thread safe. It isn't. Unless each Emacs application thread will have its own fd_handler thread. One possible solution might be to let only one thread, say the main thread, to call [NSApp run]. The other threads, when they get into ns_select, will behave as if Emacs runs in non-GUI mode, and will only call pselect. Not sure what this will mean from the POV of all threads being equal (since the delicate dance between ns_select and ns_read_socket is still unclear to me), but at least it might avoid crashes and hangs. Can you try something like that? > The communication between ns_select and fd_handler is done by > setting static variables and then running: > > c = 'g'; > emacs_write_sig (selfds[1], &c, 1); > > I don’t really know what that does. Sends something on an fd? Yes. I guess 'g' stands for GO and 's' stands for SUSPEND. These are commands to the fd_handler thread, or so it seems. Thanks.