bug#63589: [PATCH] 29.0.91; crash after creating graphical frames via emacsclient when compiled with cairo-xcb

[Eli Zaretskii <eliz@gnu.org>]

> From: Po Lu <luangruo@yahoo.com>
> Cc: tmdmelo@gmail.com,  63589@debbugs.gnu.org
> Date: Fri, 26 May 2023 16:01:01 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Why is this bad?  It isn't clean, I agree, but what problems would
> > this cause to Emacs and the user, and why is this worse than the
> > current situation where Emacs crashes?
> 
> Because if the connection to the other X server becomes very slow, or
> abruptly disappears, Emacs could lock up or crash.

Sorry, I don't understand: how is the fact that we don't close the
connection related to other connections' becoming very slow, and why
would that cause us to lock up?

In any case, it sounds like this possibility is more rare than the
situation where the user repeatedly visits files one by one via
emacsclient, each time using "C-x C-c" to finish, which closes the
connection.  So it sounds like not deleting the terminal is an
improvement, isn't it?

> > But that evidently happens already with other toolkits, doesn't it?
> > So I guess these forced deletions are very rarely used.
> 
> Connecting Emacs to multiple displays is already rarely used.  But we've
> been hearing people complain about such crashes on other toolkits a lot,
> so it is certainly an important situation to consider.

I agree.  But if Cauro-XCB behaves like those other toolkits, then we
are not worse in this respect than we already are with those other
toolkits.  So again, this sounds like an improvement.