Re: long-standing GTK bug

[Madhu]

* Po Lu <871qzktpd8.fsf @yahoo.com> :
Wrote on Wed, 02 Mar 2022 22:12:35 +0800:
> Adam Sjøgren <asjo @koldfront.dk> writes:
>
>> 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!
>
> It doesn't work.  The part of Mutter that inherited from Metacity is
> special in how it uses GTK for various reasons, so it works for them.
>
> The call to longjmp is not the problem.  Rather, it was the original
> workaround.  Removing the longjmp will just make GTK call _exit upon
> an IO error, which we cannot avoid.  (See for example the
> `_gdk_x11_display_error_event' function in the GTK source code.)

I tried to do a proof of concept using XSetIOErrorExitHandler to prove
it was possible to kill the display and still have a gtk app running.

https://gitlab.gnome.org/enometh/simple4/-/raw/master/simple.c

which seemed to work. the code is a bit crufty as it includes the
longjmp path , and i have to reread it to understand it and my headaches
are interfering with thinking. When i checked there was some other snag
in moving this to emacs