Po Lu <luangruo@yahoo.com> writes:

> Arsen Arsenović <arsen@aarsen.me> writes:
>
>> It would be indeed.
>>
>> The likelihood of crashes would be lowered if the display server event
>> loop is not kept busy by the Elisp interpreter, though, which is why a
>> separate thread would help (for instance, I suspect that the reason I
>> see crashes when sending mail on occasion is because smtpmail blocks the
>> main thread and a bunch of mouse events get queued up in the meanwhile,
>> causing libwayland to give up).
>
> If the display server crashes, the connection is closed, and GDK gives
> up when it calls `wl_display_flush' at some point and gets SIGPIPE.
> It's not related to events being queued up or whatever.

Yes, it's indeed not related in the display server crash case.  That is
not the case that concerns me in this instance, though.

The display server keeps working just fine when I see GTK call _exit.

You can simulate this by starting Emacs, suspending it, resizing the
window a bunch and clicking around, and then unsuspending it:

  ~$ emacs
  ^Z
  [1]+  Stopped                 emacs
  << Some mouse/resize spam here for a few seconds >>
  ~ 148 $ fg
  emacs
  Gdk-Message: 13:26:40.087: Lost connection to Wayland compositor.
  ~ 1 $ 

>> In either case, the better fix would be teaching GTK not to do silly
>> things on error conditions, and instead consult the user, but I'm not
>> sure how doable that is.
>
> Very easy, as was proven when this feature actually worked as intended
> sometime during the 2.14 series.  It's just that the GTK developers need
> their power fix and refuse to actually fix the problem, because ``only
> Emacs needs this fixed.''

That's what I was fearing too ;).  I know of at least one instance of
this affecting GTK apps, so "only Emacs needs this" is false.  Do you
have a link to the bug handy?  I'd like to read the history.
-- 
Arsen Arsenović