From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: bug#60144: 30.0.50; PGTK Emacs crashes after signal Date: Thu, 22 Dec 2022 11:04:05 +0200 Message-ID: <83wn6j95dm.fsf@gnu.org> References: <87edsxfop0.fsf@yahoo.com> <83359dgt7v.fsf@gnu.org> <87a63lfcz7.fsf@yahoo.com> <83y1r5f6lh.fsf@gnu.org> <875ye9f385.fsf@yahoo.com> <83fsddey48.fsf@gnu.org> <871qowgbay.fsf@yahoo.com> <83bko0gact.fsf@gnu.org> <87wn6oesfx.fsf@yahoo.com> <835ye8fweu.fsf@gnu.org> <87sfhcdulj.fsf@yahoo.com> <838rj3ea07.fsf@gnu.org> <87cz8eetvi.fsf@yahoo.com> <835ye6cdh9.fsf@gnu.org> <87o7rxd0z6.fsf@yahoo.com> <831qosc3ev.fsf@gnu.org> <871qosb50l.fsf@yahoo.com> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="6742"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Po Lu Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Dec 22 10:08:12 2022 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1p8HYi-0001Uy-0u for ged-emacs-devel@m.gmane-mx.org; Thu, 22 Dec 2022 10:08:12 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1p8HV1-0004bH-1I; Thu, 22 Dec 2022 04:04:23 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1p8HUz-0004b0-Er for emacs-devel@gnu.org; Thu, 22 Dec 2022 04:04:21 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1p8HUz-00065m-5F; Thu, 22 Dec 2022 04:04:21 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=vcTUZWaN+3K+VM55z1Xa6N0ueVLO1OjPoZl5Dx30Jpg=; b=P6TITN1gsrPE ReTpIdxU9bLzmOQbvLxqnzcnzUE5ZENofPwvNe21waQ12nVjtVjh1DKCLG4yhDZh0soEBvgYcqr5G z9Stcy/nEX7mm77YT4c5XMjcoh/G4fItXX1SJhuC9/dDQ2OMGOWR8OfZKbyEBVe7dBuzMVCCarqeJ oqpAfRGO3q6YmeDZXco73neRK98XekJ/9qkrtVxw4orRZRaeA4GCsHQh95h6ZnqvZRn4qlXdaUO42 nKAIKoHLZsZNymBH6d12VgyPfDLhmlRXIQu8FQ0Pqtdwd3dzbT1Jd2cI8+JxuG6BPQC7lBMjwgJZo nIQbdZZ+S2mcZWAFnx9yqA==; Original-Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1p8HUy-0006my-Kq; Thu, 22 Dec 2022 04:04:20 -0500 In-Reply-To: <871qosb50l.fsf@yahoo.com> (message from Po Lu on Thu, 22 Dec 2022 09:28:58 +0800) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:301783 Archived-At: > From: Po Lu > Cc: emacs-devel@gnu.org > Date: Thu, 22 Dec 2022 09:28:58 +0800 > > Eli Zaretskii writes: > > >> Under the GTK builds, there is only a single thread. The event loop > >> runs from the main thread. Those calls to note_mouse_highlight *are* > >> being done from the main thread. The problem is that it is unsafe to > >> signal in the main thread when handle_one_xevent is being called by > >> GLib, because GLib does the equivalent of this: > >> > >> static bool inside_callback; > >> > >> assert (!inside_callback); > >> inside_callback = true; > >> [call handle_one_xevent] > >> inside_callback = false; > >> > >> If handle_one_xevent signals, then inside_callback will never be set to > >> false. As a result, the next time GLib enters its own event dispatch > >> code, it will abort, leading to the crash seen here. > > > > OK, so then I ask again: why not have the function called by GTK just > > enqueue events and return, and then let read_socket_hook read the > > enqueued events and process them as they are read, in keyboard.c? > > After the function returns, it is not guaranteed that Emacs will be able > to enter read_socket_hook soon. Why is that a problem? If the event we queue includes all the data needed for processing it, why does it matter how soon it is processed? And what could delay the processing significantly in this scenario? Since these callbacks are called from the main thread, it means Emacs is not busy, and should return to the main loop very soon. Right?