Re: Qt can now survive Wayland compositor restarts

["Arsen Arsenović" <arsen@aarsen.me>]

[-- 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 --]