Qt can now survive Wayland compositor restarts

Qt can now survive Wayland compositor restarts

[Sean Whitton]

Apropos the infamous Gtk bug, I saw this piece of news I thought I
should share:
<https://codereview.qt-project.org/c/qt/qtwayland/+/377104>.

-- 
Sean Whitton

Re: Qt can now survive Wayland compositor restarts

[Dmitry Gutov]

On 10/03/2023 18:31, Sean Whitton wrote:
> Apropos the infamous Gtk bug, I saw this piece of news I thought I
> should share:
> <https://codereview.qt-project.org/c/qt/qtwayland/+/377104>.

That might not give it an advantage over GTK still: over here, all 
applications survive Alt+F2 r RET in GNOME, including Emacs.

What's (allegedly) a problem for Emacs, is the crash when the X server 
goes away. Not just the compositor.

Re: Qt can now survive Wayland compositor restarts

[Arsen Arsenović]

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


Dmitry Gutov <dgutov@yandex.ru> writes:

> On 10/03/2023 18:31, Sean Whitton wrote:
>> Apropos the infamous Gtk bug, I saw this piece of news I thought I
>> should share:
>> <https://codereview.qt-project.org/c/qt/qtwayland/+/377104>.
>
> That might not give it an advantage over GTK still: over here, all applications
> survive Alt+F2 r RET in GNOME, including Emacs.
>
> What's (allegedly) a problem for Emacs, is the crash when the X server goes
> away. Not just the compositor.

That's a different kind of compositor.  Wayland compositors are also
display servers.

GTK can definitely not survive that; the only source of instability I
see in Emacs is GTK calling _exit () because of a Wayland connection
timeout while in some blocking code (such as in smtpmail).

I was considering trying to do a separation of UI and Elisp threads as a
solution, but, seeing this happen makes me think a Qt port is easier.

I'd still like opinions on the former idea, though.  It might be
worthwhile, but I am operating with little knowledge of that part of the
code-base, so I'm unsure if there's some deeper reason behind this not
being the case today.

Though, this still makes Emacs as a server not very resilient, sadly...

Have a lovely night.
-- 
Arsen Arsenović

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 381 bytes --]

Re: Qt can now survive Wayland compositor restarts

[Björn Bidar]

See also bug#56967.

https://lists.gnu.org/r/bug-gnu-emacs/2022-08/msg00305.html

Re: Qt can now survive Wayland compositor restarts

[Eli Zaretskii]

> From: Arsen Arsenović <arsen@aarsen.me>
> Cc: Sean Whitton <spwhitton@spwhitton.name>, emacs-devel@gnu.org
> Date: Fri, 10 Mar 2023 23:17:17 +0100
> 
> I was considering trying to do a separation of UI and Elisp threads as a
> solution, but, seeing this happen makes me think a Qt port is easier.
> 
> I'd still like opinions on the former idea, though.  It might be
> worthwhile, but I am operating with little knowledge of that part of the
> code-base, so I'm unsure if there's some deeper reason behind this not
> being the case today.

FYI: the MS-Windows build of Emacs uses a separate thread for input
and UI.

Re: Qt can now survive Wayland compositor restarts

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Arsen Arsenović <arsen@aarsen.me>
>> Cc: Sean Whitton <spwhitton@spwhitton.name>, emacs-devel@gnu.org
>> Date: Fri, 10 Mar 2023 23:17:17 +0100
>> 
>> I was considering trying to do a separation of UI and Elisp threads as a
>> solution, but, seeing this happen makes me think a Qt port is easier.
>> 
>> I'd still like opinions on the former idea, though.  It might be
>> worthwhile, but I am operating with little knowledge of that part of the
>> code-base, so I'm unsure if there's some deeper reason behind this not
>> being the case today.
>
> FYI: the MS-Windows build of Emacs uses a separate thread for input
> and UI.

Likewise for the Haiku and Android ports, FWIW.

Re: Qt can now survive Wayland compositor restarts

[Arsen Arsenović]

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


Po Lu <luangruo@yahoo.com> writes:

> Eli Zaretskii <eliz@gnu.org> writes:
>
>>> From: Arsen Arsenović <arsen@aarsen.me>
>>> Cc: Sean Whitton <spwhitton@spwhitton.name>, emacs-devel@gnu.org
>>> Date: Fri, 10 Mar 2023 23:17:17 +0100
>>> 
>>> I was considering trying to do a separation of UI and Elisp threads as a
>>> solution, but, seeing this happen makes me think a Qt port is easier.
>>> 
>>> I'd still like opinions on the former idea, though.  It might be
>>> worthwhile, but I am operating with little knowledge of that part of the
>>> code-base, so I'm unsure if there's some deeper reason behind this not
>>> being the case today.
>>
>> FYI: the MS-Windows build of Emacs uses a separate thread for input
>> and UI.
>
> Likewise for the Haiku and Android ports, FWIW.

Reassuring, thanks for the info.  I'll try making some time to do the
same for PGTK, though I can't promise anything.
-- 
Arsen Arsenović

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 381 bytes --]

Re: Qt can now survive Wayland compositor restarts

[Po Lu]

Arsen Arsenović <arsen@aarsen.me> writes:

> Po Lu <luangruo@yahoo.com> writes:
>
>> Eli Zaretskii <eliz@gnu.org> writes:
>>
>>>> From: Arsen Arsenović <arsen@aarsen.me>
>>>> Cc: Sean Whitton <spwhitton@spwhitton.name>, emacs-devel@gnu.org
>>>> Date: Fri, 10 Mar 2023 23:17:17 +0100
>>>> 
>>>> I was considering trying to do a separation of UI and Elisp threads as a
>>>> solution, but, seeing this happen makes me think a Qt port is easier.
>>>> 
>>>> I'd still like opinions on the former idea, though.  It might be
>>>> worthwhile, but I am operating with little knowledge of that part of the
>>>> code-base, so I'm unsure if there's some deeper reason behind this not
>>>> being the case today.
>>>
>>> FYI: the MS-Windows build of Emacs uses a separate thread for input
>>> and UI.
>>
>> Likewise for the Haiku and Android ports, FWIW.
>
> Reassuring, thanks for the info.  I'll try making some time to do the
> same for PGTK, though I can't promise anything.

Do what?

If you want to fix the GTK crash, you will have to run the GTK stuff in
a separate *process*.  Now that would be a real pain.

Thanks.

Re: Qt can now survive Wayland compositor restarts

[Arsen Arsenović]

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


Po Lu <luangruo@yahoo.com> writes:

> Arsen Arsenović <arsen@aarsen.me> writes:
>
>> Po Lu <luangruo@yahoo.com> writes:
>>
>>> Eli Zaretskii <eliz@gnu.org> writes:
>>>
>>>>> From: Arsen Arsenović <arsen@aarsen.me>
>>>>> Cc: Sean Whitton <spwhitton@spwhitton.name>, emacs-devel@gnu.org
>>>>> Date: Fri, 10 Mar 2023 23:17:17 +0100
>>>>> 
>>>>> I was considering trying to do a separation of UI and Elisp threads as a
>>>>> solution, but, seeing this happen makes me think a Qt port is easier.
>>>>> 
>>>>> I'd still like opinions on the former idea, though.  It might be
>>>>> worthwhile, but I am operating with little knowledge of that part of the
>>>>> code-base, so I'm unsure if there's some deeper reason behind this not
>>>>> being the case today.
>>>>
>>>> FYI: the MS-Windows build of Emacs uses a separate thread for input
>>>> and UI.
>>>
>>> Likewise for the Haiku and Android ports, FWIW.
>>
>> Reassuring, thanks for the info.  I'll try making some time to do the
>> same for PGTK, though I can't promise anything.
>
> Do what?

A separate UI thread.

> If you want to fix the GTK crash, you will have to run the GTK stuff in
> a separate *process*.  Now that would be a real pain.

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

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.

> Thanks.


-- 
Arsen Arsenović

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 381 bytes --]

Re: Qt can now survive Wayland compositor restarts

[Po Lu]

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.

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

Re: Qt can now survive Wayland compositor restarts

[Arsen Arsenović]

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


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ć

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 381 bytes --]

Re: Qt can now survive Wayland compositor restarts

[Po Lu]

Arsen Arsenović <arsen@aarsen.me> writes:

> 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 $ 

Well, in this case the compositor has still closed the connection, so
the consequences are the same.

The Lisp interpreter should periodically poll for input and also read
input as it becomes available, so this should not be a problem with
long-running Lisp code.  If it is, please report a bug.  Thanks.

Re: Qt can now survive Wayland compositor restarts

[Arsen Arsenović]

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


Po Lu <luangruo@yahoo.com> writes:

> Well, in this case the compositor has still closed the connection, so
> the consequences are the same.
>
> The Lisp interpreter should periodically poll for input and also read
> input as it becomes available, so this should not be a problem with
> long-running Lisp code.  If it is, please report a bug.  Thanks.

Hm, interesting.  I'll try to get an actionable bug report out of it,
then.  I don't really have great reproduction steps currently, usually
it's just "hope it doesn't happen when sending an email", which I don't
think is sufficient for a bug report.

Thanks for the heads-up.
-- 
Arsen Arsenović

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 381 bytes --]

Re: Qt can now survive Wayland compositor restarts

[Madhu]

* Arsen Arsenović <86a60j1q55.fsf @aarsen.me> :
Wrote on Sat, 11 Mar 2023 12:23:28 +0100:
> Po Lu <luangruo@yahoo.com> writes:
>>> Reassuring, thanks for the info.  I'll try making some time to do the
>>> same for PGTK, though I can't promise anything.
>>
>> Do what?
>
> A separate UI thread.

AIUI all gtk calls have to happen on the default main context and so on
the.  Even if this is a different thread, the issues around locking the
default main context make the glib mainloop go mad.

There's a lot of history, too much of it, so it obscures. I think the
bug I filed is at https://gitlab.gnome.org/GNOME/gtk/-/issues/2315

[In your case I think the _exit() there only to prevent the glib main
loop from spamming errors when it gets into an inconsistent state, the
issues are in glib, but I've not refreshed my unreliable memory]

Re: Qt can now survive Wayland compositor restarts

[Po Lu]

Dmitry Gutov <dgutov@yandex.ru> writes:

> That might not give it an advantage over GTK still: over here, all
> applications survive Alt+F2 r RET in GNOME, including Emacs.

It does - the Wayland compositor is also the display server.

Ironically, Qt deals badly with X window manager restarts, however, when
the new window manager supports a different set of features from the old
one.

Re: Qt can now survive Wayland compositor restarts

[Po Lu]

Sean Whitton <spwhitton@spwhitton.name> writes:

> Apropos the infamous Gtk bug, I saw this piece of news I thought I
> should share:
> <https://codereview.qt-project.org/c/qt/qtwayland/+/377104>.

I think this is a good thing for Qt users, but not good enough for us.
The problem is that Qt will keep trying to reconnect in a loop, instead
of closing the display connection, and telling Emacs that the display
has been closed.  That doesn't work if the display server has actually
gone away and has not crashed, only to restart moments later.  Emacs
must be given full control over display connections.