From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: =?utf-8?Q?Adam_Sj=C3=B8gren?= Newsgroups: gmane.emacs.devel Subject: Re: long-standing GTK bug Date: Tue, 01 Mar 2022 22:23:19 +0100 Organization: koldfront - analysis & revolution, Copenhagen, Denmark Message-ID: <87pmn5cqpk.fsf@tullinup.koldfront.dk> References: <83zhbcg6s4.fsf@gnu.org> <87r1wng2ki.fsf@linaro.org> <83o8rrenn1.fsf@gnu.org> <87blnr6uck.fsf@tullinup.koldfront.dk> <87wo5kumkn.fsf_-_@tullinup.koldfront.dk> <86ftc5hc8j.fsf@gmail.com> <87d079io10.fsf@tullinup.koldfront.dk> <87ftbyokll.fsf@tullinup.koldfront.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="29416"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) To: emacs-devel@gnu.org Cancel-Lock: sha1:ieFmUT3VJdLFFS5ya6Iy2bP+iDA= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Mar 01 22:25:23 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 1nP9zn-0007SF-Hx for ged-emacs-devel@m.gmane-mx.org; Tue, 01 Mar 2022 22:25:23 +0100 Original-Received: from localhost ([::1]:49938 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nP9zm-000271-EE for ged-emacs-devel@m.gmane-mx.org; Tue, 01 Mar 2022 16:25:22 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:51080) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nP9y1-0000dW-BI for emacs-devel@gnu.org; Tue, 01 Mar 2022 16:23:33 -0500 Original-Received: from ciao.gmane.io ([116.202.254.214]:54060) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nP9xy-0000Qx-0P for emacs-devel@gnu.org; Tue, 01 Mar 2022 16:23:33 -0500 Original-Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1nP9xu-0004xa-OT for emacs-devel@gnu.org; Tue, 01 Mar 2022 22:23:26 +0100 X-Injected-Via-Gmane: http://gmane.org/ OpenPGP: id=476630590A231909B0A0961A49D0746121BDE416; url=https://asjo.koldfront.dk/gpg.asc X-Now-Playing: Shoot You in the Back (live), The Best of (cd 2) =?utf-8?Q?=28Mot=C3=B6rhead=29?= X-Face: )qY&CseJ?.:=8F#^~GcSA?F=9eu'{KAFfL1C3/A&:nE?PW\i65"ba0NS)97, Q(^@xk}n4Ou rPuR#V8I(J_@~H($[ym:`K_+]*kjvW>xH5jbgLBVFGXY:(#4P>zVBklLbdL&XxL\M)%T}3S/IS9lMJ ^St'=VZBR 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" Xref: news.gmane.io gmane.emacs.devel:286758 Archived-At: You may recall that around 92 weeks ago I wrote: > However, my quick test required me to copy the struct _GMainContext > definition from glib/gmain.c into xterm.c, which is not the correct way > to go about this, I'm sure. > > I do feel that this is progress, though. Now we just need to figure out > the right way to handle it. > > If that is for gdk_display_close() to reset the in_check_or_prepare > counter, or if it is something that can be changed in Emacs, I don't > know. > > I have updated the current GTK issue⁴ with my observations, but I'm > hoping for some input from emacs-devel as well. A recent blog post: https://tychoish.com/post/the-emacs-daemon-gtk-bug-a-parable/ made me aware of the continued discussion that happened on the GTK issue 11 months ago, which I had previously missed. A very interesting comment is this one by Michel Dänzer: FWIW, the upcoming release 40 of mutter (which uses GTK3 for drawing X11 client window decorations) is able to survive Xwayland dying abruptly, using the new XSetIOErrorExitHandler API (which removes the need for longjmp hacks) available as of libX11 1.7.0. · https://gitlab.gnome.org/GNOME/gtk/-/issues/2315#note_1052481 Which sounds like exactly what is needed, doesn't it? Switch from using the current XIOErrorHandler to the "new" XSetIOErrorExitHandler API to avoid the longjmp and the sketchy patchy hackery I ended up with. This API is available in libX11 1.7.0 - I just checked the version in Debian stable, and it is 1.7.2, so it's not some outrageously new bleeding edge addition. Now we just need someone with libX11 API chops to start ... eh, chopping! 11 years down the line, feeling optimistic, Adam -- "Jeg er som en pære når jeg springer og mister min Adam Sjøgren fatning!" asjo@koldfront.dk