emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: long-standing GTK bug


From: Po Lu
Subject: Re: long-standing GTK bug
Date: Wed, 02 Mar 2022 22:12:35 +0800
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.91 (gnu/linux)

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.)

Thanks.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]