From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Alan Third Newsgroups: gmane.emacs.bugs Subject: bug#25265: make-thread crashes in OS X 10.6 Date: Wed, 28 Dec 2016 19:36:33 +0000 Message-ID: <20161228193633.GA47290@breton.holly.idiocy.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> 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 1482953833 23807 195.159.176.226 (28 Dec 2016 19:37:13 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 28 Dec 2016 19:37:13 +0000 (UTC) User-Agent: Mutt/1.7.1 (2016-10-04) Cc: charles@aurox.ch, 25265@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed Dec 28 20:37:08 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 1cMK28-0005U6-1z for geb-bug-gnu-emacs@m.gmane.org; Wed, 28 Dec 2016 20:37:08 +0100 Original-Received: from localhost ([::1]:60696 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cMK2B-0008FJ-Bf for geb-bug-gnu-emacs@m.gmane.org; Wed, 28 Dec 2016 14:37:11 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:52828) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cMK25-0008F0-JS for bug-gnu-emacs@gnu.org; Wed, 28 Dec 2016 14:37:06 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cMK22-0000wg-Ew for bug-gnu-emacs@gnu.org; Wed, 28 Dec 2016 14:37:05 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:42898) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1cMK22-0000wa-AZ for bug-gnu-emacs@gnu.org; Wed, 28 Dec 2016 14:37:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1cMK22-0001ei-23 for bug-gnu-emacs@gnu.org; Wed, 28 Dec 2016 14:37:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Alan Third Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 28 Dec 2016 19:37:02 +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.14829538046339 (code B ref 25265); Wed, 28 Dec 2016 19:37:02 +0000 Original-Received: (at 25265) by debbugs.gnu.org; 28 Dec 2016 19:36:44 +0000 Original-Received: from localhost ([127.0.0.1]:58297 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cMK1k-0001eB-07 for submit@debbugs.gnu.org; Wed, 28 Dec 2016 14:36:44 -0500 Original-Received: from mail-wj0-f182.google.com ([209.85.210.182]:34196) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cMK1h-0001dt-Rn for 25265@debbugs.gnu.org; Wed, 28 Dec 2016 14:36:42 -0500 Original-Received: by mail-wj0-f182.google.com with SMTP id sd9so158860828wjb.1 for <25265@debbugs.gnu.org>; Wed, 28 Dec 2016 11:36:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20161025; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to :user-agent; bh=pXDYVukJ4Rr/32TPdfKykHevLUZe9MJMaZnfPJ4M2DE=; b=BtYHCby6I4YrO9cyO47EowwMhHXlGVvB+BeFoN8wxc0F3xGzsvn/VToEx+INEbXtx7 amOjAd+7V2KZTxwGY95CYof5gD9w6uWU81krBIIfjgr6h3qNWjPbsEhCBmik3RNsGcDp Mqd5oJdQsYSds0GLqG204UE7R848Gn3hS90ZRFg0TC3X8SaLgD9wAv6PQ20b1G9B992j 2zQ3kvj22GEMCcGt2cdaph9+RgBM8beaNsUawk3y7Cerq4zBQGqfI4xBXm7mIBDI540Q mJP3kFck8CtAl4oLx0GN7WZbxnYA96MvxoFW42YtIFPGJICant/Nj3qwpkCOQXlBIPbT h/Zw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition :content-transfer-encoding:in-reply-to:user-agent; bh=pXDYVukJ4Rr/32TPdfKykHevLUZe9MJMaZnfPJ4M2DE=; b=hjEl8vNCFcgRc+Klnq4c5Yu/5btsVHwqxjy51jPIAYq8FWvQnvg8lZVizGWcfuq1X5 AEhfpikO9S/sUjI7bpZqoiY7jfZo/aRhRBYL9pZQZtQgevz9OatJsYN8CjQCksvYFM7y 7AzhgzrNgo99gtBYIStkghAvUHiyyP4R43r/7eo/wUOSI0OK0hhaNwF3X/+ICpWGjtlr i3PjAZdVgO1qVEacCNjISuSycilDa/HkdRxqzpRGUE1whMxnzcWn+W39eKIe9qF3ZZwZ 1DHQwKltD0QNL2WLhJ7BnvuJrCj53zzw7mNO5cHSBOcQnGioj3FRSfwnIwFdsygPNGBM zSAA== X-Gm-Message-State: AIkVDXKzpo+5M7mwC15H72ky8gnqYzRPHqoFVt29vc34Mt1g1cY6phL43k21vDeA6Lz16w== X-Received: by 10.194.59.98 with SMTP id y2mr33320523wjq.166.1482953796008; Wed, 28 Dec 2016 11:36:36 -0800 (PST) Original-Received: from breton.holly.idiocy.org (ip6-2001-08b0-03f8-8129-e98a-1e50-f566-df0e.holly.idiocy.org. [2001:8b0:3f8:8129:e98a:1e50:f566:df0e]) by smtp.gmail.com with ESMTPSA id 197sm62055217wmy.16.2016.12.28.11.36.35 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 28 Dec 2016 11:36:35 -0800 (PST) Content-Disposition: inline In-Reply-To: <83bmvxwrp4.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:127528 Archived-At: On Tue, Dec 27, 2016 at 01:13:11PM +0200, Eli Zaretskii wrote: > > Date: Tue, 27 Dec 2016 10:44:24 +0000 > > From: Alan Third > > Cc: charles@aurox.ch, 25265@debbugs.gnu.org > > > > > > [NSApp run]; > > > > > > > > > > Can this part and its surrounding code be made thread-safe? > > > > > > > > I think this particular method call has to be done *only* from the > > > > main thread. I imagine that could be a problem. > > > > > > It could be a problem, yes. But what does this do, exactly, and why > > > does it need to be called as part of ns_select? > > > > It runs an event loop that picks up all GUI events and then dispatches > > them. It’s part of NextStep. It’s unclear to me why it’s run in > > ns_select, but presumably it’s because it needs to be run somewhere > > and whoever wrote it thought that was a good place. > > > > If we need to, I expect we could move it to its own thread. That seems > > to be a known pattern in the GNUStep/Cocoa world. > > 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? 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]. The following is for my own future reference, if nothing else. 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]. 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, which then ends. 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. 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? Then it writes back to the same global variables for ns_select to pick up. Now I’ve written it down it seems a lot less complicated... -- Alan Third