From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#36609: 27.0.50; Possible race-condition in threading implementation Date: Sat, 13 Jul 2019 18:03:35 +0300 Message-ID: <83wogmyo1k.fsf@gnu.org> References: <87muhks3b5.fsf@hochschule-trier.de> <83muhj2zmb.fsf@gnu.org> <83ims72xcj.fsf@gnu.org> <83a7dj2sz9.fsf@gnu.org> <835zo72jmr.fsf@gnu.org> <834l3r2jbe.fsf@gnu.org> <8336jb2fhq.fsf@gnu.org> Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="262496"; mail-complaints-to="usenet@blaine.gmane.org" Cc: 36609@debbugs.gnu.org, politza@hochschule-trier.de To: Pip Cet Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Jul 13 17:20:17 2019 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1hmJor-0015wZ-VC for geb-bug-gnu-emacs@m.gmane.org; Sat, 13 Jul 2019 17:20:14 +0200 Original-Received: from localhost ([::1]:56758 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hmJZP-0007Y3-4X for geb-bug-gnu-emacs@m.gmane.org; Sat, 13 Jul 2019 11:04:15 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:54123) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hmJZM-0007Xs-9v for bug-gnu-emacs@gnu.org; Sat, 13 Jul 2019 11:04:13 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hmJZE-0004KF-6t for bug-gnu-emacs@gnu.org; Sat, 13 Jul 2019 11:04:08 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:34274) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hmJZB-0004Jw-VW for bug-gnu-emacs@gnu.org; Sat, 13 Jul 2019 11:04:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1hmJZB-0005gp-Pp for bug-gnu-emacs@gnu.org; Sat, 13 Jul 2019 11:04:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 13 Jul 2019 15:04:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 36609 X-GNU-PR-Package: emacs Original-Received: via spool by 36609-submit@debbugs.gnu.org id=B36609.156303023921862 (code B ref 36609); Sat, 13 Jul 2019 15:04:01 +0000 Original-Received: (at 36609) by debbugs.gnu.org; 13 Jul 2019 15:03:59 +0000 Original-Received: from localhost ([127.0.0.1]:43095 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hmJZ8-0005gY-Ao for submit@debbugs.gnu.org; Sat, 13 Jul 2019 11:03:58 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:41709) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hmJZ6-0005gK-St for 36609@debbugs.gnu.org; Sat, 13 Jul 2019 11:03:57 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:36235) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hmJYz-0004DX-Ed; Sat, 13 Jul 2019 11:03:50 -0400 Original-Received: from [176.228.60.248] (port=3536 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1hmJYx-0001fc-VE; Sat, 13 Jul 2019 11:03:49 -0400 In-reply-to: (message from Pip Cet on Sat, 13 Jul 2019 14:37:25 +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: 209.51.188.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:162906 Archived-At: > From: Pip Cet > Date: Sat, 13 Jul 2019 14:37:25 +0000 > Cc: 36609@debbugs.gnu.org, politza@hochschule-trier.de > > Well, I think we're going to have to do one or more of the following: > > - have a race condition > - access glib-locked data from the "wrong" thread (another Emacs thread) > - release the glib lock from the "wrong" thread (another Emacs thread) > > Of these, the second is the best alternative, I think: we simply grab > the g_main_context lock globally, acting for all Emacs threads, and > the last thread to require it releases it when it leaves xg_select. I agree. > As long as there's at least one thread in the critical section of > xg_select, we hold the lock, but access to the context isn't > necessarily from the thread which locked it. Hmm... wouldn't this cause us always hold that lock when there's more than one Lisp thread? And if so, what will that do to GTK and its own threads, which also want to acquire the Glib context? IOW, I guess I don't understand what problem would the proposed changes solve that the current code doesn't. Can you tell? > > Hmm... how would this work with your patch? Suppose one thread calls > > xg_select, acquires the Glib lock, sets its holding_glib_lock flag, > > then releases the global Lisp lock and calls pselect. Since the > > global Lisp lock is now up for grabs, some other Lisp thread can > > acquire it and start running. > > And when it starts running, it releases the Glib lock. But only if its holding_glib_lock flag is set, which is not necessarily true. For example, what about a thread that was just created, and never called xg_select yet? > Okay, that sounds like option #2 above. The attached patch exposes > glib externals to the generic code, but it appears to work. If you > think the approach is okay, I'll move the glib-specific parts to > xgselect.c (if that's okay). Yes, we should have accessor functions in xgselect.c instead of letting thread.c etc. access the GTK/Glib data directly. But I still would like to understand why we need to maintain a flag per thread. Also, I think I lost the context: does this attempt to solve the original problem reported by Andreas, or only the problem reported by you later in the discussion? Thanks.