Re: Question about pgtk -- is it meant to fix the disconnect crash bug?

[chad <yandros@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2195 bytes --]

On Thu, Mar 4, 2021 at 2:58 PM Daniele Nicolodi <daniele@grinta.net> wrote:

> The last time I looked at this the GTK maintainers are interested in
> investigating the bug and fixing it in GTK as long as it does not
> involve debugging Emacs but a more manageable reproducer of the issue.
> AFAIK, no one tried to provide one.
>

That actually does not match my understanding; if I remember correctly, the
GTK people felt that emacs was doing something that they did not want to
support, and since no "well behaved" GTK applications had reported the
problem, they were thus were unwilling to continue. I might be
misremembering.

Also, the last time I looked, Emacs aborts() when it detects the
> condition that causes the bug, thus fixing the bug in GTK does not
> automatically fix Emacs.
>

Emacs added that code as a response to the GTK bug, because calling abort()
itself is minorly cleaner than allowing the crash from _exit() in the
library.

At heart, emacs is trying to use a niche feature that was spec'd but never
fully implemented in gtk/gdk. Nobody else wants to use that feature,
because there just aren't that many apps that want to hop around between
open and closed displays (like emacs --daemon does) AND that also have a
lot of long-lived state (most would be fine with simply closing and
restarting). Web browsers are the nearest candidate that comes to mind, and
they have already invested large-to-massive effort in the alternative "run
distinct copies everywhere, including your phone, and layer on a sync
service for the few places where you might care".

This creates an environment where the GTK maintainers weigh a bunch of
groddy low-level work to support a feature almost no one wants on one side
against a client base that has the highly-functional "just use Lucid"
alternative on the other. This world doesn't produce a lot of motivation to
solve the problem, and the solution will likely (if I understand the
decade-plus-old bug-thread) require fairly low-level changes to gtk/gdk, so
the solver needs to be very familiar with gdk internals, so the friction is
quite high. In the meantime, X11 is due to be obsoleted every few years for
the last decade...

~Chad

[-- Attachment #2: Type: text/html, Size: 2832 bytes --]