Re: master f0ff20be51: * src/emacs.c (main): Improve accuracy of daemon warning message on PGTK.

Re: master f0ff20be51: * src/emacs.c (main): Improve accuracy of daemon warning message on PGTK.

[Sean Whitton]

Hello,

On Tue 05 Apr 2022 at 10:30pm -04, Po Lu via Mailing list for Emacs changes wrote:

> diff --git a/src/emacs.c b/src/emacs.c
> index 2a4dcc2c2c..acb409fcb7 100644
> --- a/src/emacs.c
> +++ b/src/emacs.c
> @@ -1734,12 +1734,25 @@ main (int argc, char **argv)
>  	sockfd = SD_LISTEN_FDS_START;
>  #endif /* HAVE_LIBSYSTEMD */
>
> -#ifdef USE_GTK
> +      /* On X, the bug happens because we call abort to avoid GLib
> +	 crashes upon a longjmp in our X error handler.
> +
> +         On PGTK, GTK calls exit in its own error handlers for either
> +         X or Wayland.  Display different messages depending on the
> +         window system to avoid referring users to the wrong GTK bug
> +         report.  */
> +#ifdef HAVE_PGTK
> +      fputs ("Due to a limitation in GTK 3, Emacs built with PGTK will simply exit when a"
> +	     "display connection is closed."
> +	     "\nThere is no way to fix this problem, so if you want to use Emacs on Wayland"
> +	     "on multiple displays and have Emacs survive disconnects, you lose.",

Nice idea to avoid referring users to a bug report that doesn't apply to
pgtk.  But is there truly "no way to fix this problem" in the pgtk case
too?  Is it really that fundamental to the design of GTK3?

-- 
Sean Whitton

Re: master f0ff20be51: * src/emacs.c (main): Improve accuracy of daemon warning message on PGTK.

[Robert Pluim]

>>>>> On Wed, 06 Apr 2022 08:37:20 -0700, Sean Whitton <spwhitton@spwhitton.name> said:
    >> +#ifdef HAVE_PGTK
    >> +      fputs ("Due to a limitation in GTK 3, Emacs built with PGTK will simply exit when a"
    >> +	     "display connection is closed."
    >> +	     "\nThere is no way to fix this problem, so if you want to use Emacs on Wayland"
    >> +	     "on multiple displays and have Emacs survive disconnects, you lose.",

    Sean> Nice idea to avoid referring users to a bug report that doesn't apply to
    Sean> pgtk.  But is there truly "no way to fix this problem" in the pgtk case
    Sean> too?  Is it really that fundamental to the design of GTK3?

There is no way for *emacs* to fix this problem. The GTK guys have
been sitting on it for 15 years. Iʼm sure they could fix it if they
wanted to.

Robert
-- 

Re: master f0ff20be51: * src/emacs.c (main): Improve accuracy of daemon warning message on PGTK.

[Sean Whitton]

Hello,

On Wed 06 Apr 2022 at 05:44PM +02, Robert Pluim wrote:

>>>>>> On Wed, 06 Apr 2022 08:37:20 -0700, Sean Whitton <spwhitton@spwhitton.name> said:
>     >> +#ifdef HAVE_PGTK
>     >> +      fputs ("Due to a limitation in GTK 3, Emacs built with PGTK will simply exit when a"
>     >> +	     "display connection is closed."
>     >> +	     "\nThere is no way to fix this problem, so if you want to use Emacs on Wayland"
>     >> +	     "on multiple displays and have Emacs survive disconnects, you lose.",
>
>     Sean> Nice idea to avoid referring users to a bug report that doesn't apply to
>     Sean> pgtk.  But is there truly "no way to fix this problem" in the pgtk case
>     Sean> too?  Is it really that fundamental to the design of GTK3?
>
> There is no way for *emacs* to fix this problem. The GTK guys have
> been sitting on it for 15 years. Iʼm sure they could fix it if they
> wanted to.

That is my understanding of the X11 bug, but the change made me think
that the status of the bug as it applies to pgtk might be subtly
different.

-- 
Sean Whitton

Re: master f0ff20be51: * src/emacs.c (main): Improve accuracy of daemon warning message on PGTK.

[Óscar Fuentes]

Sean Whitton <spwhitton@spwhitton.name> writes:

> Hello,
>
> On Wed 06 Apr 2022 at 05:44PM +02, Robert Pluim wrote:
>
>>>>>>> On Wed, 06 Apr 2022 08:37:20 -0700, Sean Whitton <spwhitton@spwhitton.name> said:
>>     >> +#ifdef HAVE_PGTK
>>     >> +      fputs ("Due to a limitation in GTK 3, Emacs built with PGTK will simply exit when a"
>>     >> +	     "display connection is closed."
>>     >> +	     "\nThere is no way to fix this problem, so if you want to use Emacs on Wayland"
>>     >> +	     "on multiple displays and have Emacs survive disconnects, you lose.",
>>
>>     Sean> Nice idea to avoid referring users to a bug report that doesn't apply to
>>     Sean> pgtk.  But is there truly "no way to fix this problem" in the pgtk case
>>     Sean> too?  Is it really that fundamental to the design of GTK3?
>>
>> There is no way for *emacs* to fix this problem. The GTK guys have
>> been sitting on it for 15 years. Iʼm sure they could fix it if they
>> wanted to.
>
> That is my understanding of the X11 bug, but the change made me think
> that the status of the bug as it applies to pgtk might be subtly
> different.

Is it possible at all to use the PGTK port on multiple graphical
displays? Wayland does not provide network transparency.

Re: master f0ff20be51: * src/emacs.c (main): Improve accuracy of daemon warning message on PGTK.

[Po Lu]

Óscar Fuentes <ofv@wanadoo.es> writes:

> Is it possible at all to use the PGTK port on multiple graphical
> displays? Wayland does not provide network transparency.

X isn't network-transparent for the same reasons Wayland isn't: DRI2,
DRI3, GLX (unless you use indirect rendering) and MIT-SHM are not
network transparent.  That doesn't mean the entire protocol can be
discarded as "not network transparent", and with various small proxies
both X and Wayland can be made completely network transparent.

Besides, you can run multiple Wayland displays locally as well.

Re: master f0ff20be51: * src/emacs.c (main): Improve accuracy of daemon warning message on PGTK.

[Po Lu]

Sean Whitton <spwhitton@spwhitton.name> writes:

> Nice idea to avoid referring users to a bug report that doesn't apply to
> pgtk.  But is there truly "no way to fix this problem" in the pgtk case
> too?  Is it really that fundamental to the design of GTK3?

Yes, 100%.  GDK just calls `_exit' on an IO error.  You cannot even run
an atexit handler.

And since we don't have control over Xlib when built with PGTK, there's
no way to run code before GDK's own IO error handler either.

Re: master f0ff20be51: * src/emacs.c (main): Improve accuracy of daemon warning message on PGTK.

[Sean Whitton]

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

Hello,

On Thu 07 Apr 2022 at 08:28am +08, Po Lu wrote:

> Sean Whitton <spwhitton@spwhitton.name> writes:
>
>> Nice idea to avoid referring users to a bug report that doesn't apply to
>> pgtk.  But is there truly "no way to fix this problem" in the pgtk case
>> too?  Is it really that fundamental to the design of GTK3?
>
> Yes, 100%.  GDK just calls `_exit' on an IO error.  You cannot even run
> an atexit handler.
>
> And since we don't have control over Xlib when built with PGTK, there's
> no way to run code before GDK's own IO error handler either.

Thanks.  I'd like to install the attached patch to preempt questions
like mine; any objections?  I still have some stuff in my init.el based
on the hope that this could be fixed; I'll probably remove it now :(

-- 
Sean Whitton

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-src-emacs.c-main-Say-that-the-problem-is-fundamental.patch --]
[-- Type: text/x-diff, Size: 1119 bytes --]

From adecae1728630541286b4a83406e3c863e0c8f4c Mon Sep 17 00:00:00 2001
From: Sean Whitton <spwhitton@spwhitton.name>
Date: Wed, 6 Apr 2022 17:45:55 -0700
Subject: [PATCH] ; * src/emacs.c (main): Say that the problem is fundamental
 to GTK.

---
 src/emacs.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/emacs.c b/src/emacs.c
index acb409fcb7..79f4f54f6f 100644
--- a/src/emacs.c
+++ b/src/emacs.c
@@ -1744,8 +1744,8 @@ main (int argc, char **argv)
 #ifdef HAVE_PGTK
       fputs ("Due to a limitation in GTK 3, Emacs built with PGTK will simply exit when a"
 	     "display connection is closed."
-	     "\nThere is no way to fix this problem, so if you want to use Emacs on Wayland"
-	     "on multiple displays and have Emacs survive disconnects, you lose.",
+	     "\nThe limitation is fundamental to GTK on Wayland, so Emacs on Wayland"
+	     "with multiple displays is unlikely ever to be able to survive disconnections.",
 	     stderr);
 #elif defined USE_GTK
       fputs ("\nWarning: due to a long standing Gtk+ bug\nhttps://gitlab.gnome.org/GNOME/gtk/issues/221\n\
-- 
2.30.2

Re: master f0ff20be51: * src/emacs.c (main): Improve accuracy of daemon warning message on PGTK.

[Po Lu]

Sean Whitton <spwhitton@spwhitton.name> writes:

> Thanks.  I'd like to install the attached patch to preempt questions
> like mine; any objections?  I still have some stuff in my init.el based
> on the hope that this could be fixed; I'll probably remove it now :(

No objections here, if nobody else has any I'll install this.  Thanks.

> From adecae1728630541286b4a83406e3c863e0c8f4c Mon Sep 17 00:00:00 2001
> From: Sean Whitton <spwhitton@spwhitton.name>
> Date: Wed, 6 Apr 2022 17:45:55 -0700
> Subject: [PATCH] ; * src/emacs.c (main): Say that the problem is fundamental
>  to GTK.
>
> ---
>  src/emacs.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/src/emacs.c b/src/emacs.c
> index acb409fcb7..79f4f54f6f 100644
> --- a/src/emacs.c
> +++ b/src/emacs.c
> @@ -1744,8 +1744,8 @@ main (int argc, char **argv)
>  #ifdef HAVE_PGTK
>        fputs ("Due to a limitation in GTK 3, Emacs built with PGTK will simply exit when a"
>  	     "display connection is closed."
> -	     "\nThere is no way to fix this problem, so if you want to use Emacs on Wayland"
> -	     "on multiple displays and have Emacs survive disconnects, you lose.",
> +	     "\nThe limitation is fundamental to GTK on Wayland, so Emacs on Wayland"
> +	     "with multiple displays is unlikely ever to be able to survive disconnections.",
>  	     stderr);
>  #elif defined USE_GTK
>        fputs ("\nWarning: due to a long standing Gtk+ bug\nhttps://gitlab.gnome.org/GNOME/gtk/issues/221\n\

Re: master f0ff20be51: * src/emacs.c (main): Improve accuracy of daemon warning message on PGTK.

[Stefan Monnier]

>>> Nice idea to avoid referring users to a bug report that doesn't apply to
>>> pgtk.  But is there truly "no way to fix this problem" in the pgtk case
>>> too?  Is it really that fundamental to the design of GTK3?
>>
>> Yes, 100%.  GDK just calls `_exit' on an IO error.  You cannot even run
>> an atexit handler.
>>
>> And since we don't have control over Xlib when built with PGTK, there's
>> no way to run code before GDK's own IO error handler either.
>
> Thanks.  I'd like to install the attached patch to preempt questions
> like mine; any objections?  I still have some stuff in my init.el based
> on the hope that this could be fixed; I'll probably remove it now :(

FWIW, I think "fundamental" is a bit strong here.  I don't see any
evidence that the design of the API makes it impossible.  It seems more
like a problem with the current implementation or a problem fixable with
the addition of a couple new functions/hooks in the API.


        Stefan

Re: master f0ff20be51: * src/emacs.c (main): Improve accuracy of daemon warning message on PGTK.

[Po Lu]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> FWIW, I think "fundamental" is a bit strong here.  I don't see any
> evidence that the design of the API makes it impossible.  It seems more
> like a problem with the current implementation

I think the problem is quite fundamental to the current implementation
of GDK: lots of stuff is left unfreed when a display is programmatically
disconnected as-is, and freeing even that typically requires a working
connection to the display server.  Which is unattainable when a display
disconnects due to an IO error.

Re: master f0ff20be51: * src/emacs.c (main): Improve accuracy of daemon warning message on PGTK.

[Stefan Monnier]

>> FWIW, I think "fundamental" is a bit strong here.  I don't see any
>> evidence that the design of the API makes it impossible.  It seems more
>> like a problem with the current implementation
> I think the problem is quite fundamental to the current implementation
> of GDK:

Fundamental to the implementation means that it can be fixed without
changing the design of the API ;-)

> lots of stuff is left unfreed when a display is programmatically
> disconnected as-is, and freeing even that typically requires a working
> connection to the display server.  Which is unattainable when a display
> disconnects due to an IO error.

I suspect it's worse than that, since "left unfreed" would just lead to
memory leaks, which I suspect could be tolerable (and in any case
much better than what we have now).


        Stefan

Re: master f0ff20be51: * src/emacs.c (main): Improve accuracy of daemon warning message on PGTK.

[Sean Whitton]

Hello,

On Wed 06 Apr 2022 at 11:16pm -04, Stefan Monnier wrote:

>>> FWIW, I think "fundamental" is a bit strong here.  I don't see any
>>> evidence that the design of the API makes it impossible.  It seems more
>>> like a problem with the current implementation
>> I think the problem is quite fundamental to the current implementation
>> of GDK:
>
> Fundamental to the implementation means that it can be fixed without
> changing the design of the API ;-)

I do see what you mean -- and please do suggest another word if you have
one in mind -- but in this case I am not sure the distinction between
fundamental-to-the-API and fundamental-to-the-implementation matters.
The problem is in a different class to just a bug that upstream doesn't
seem very motivated to fix, and that matters from a user's point of
view.

-- 
Sean Whitton

Re: master f0ff20be51: * src/emacs.c (main): Improve accuracy of daemon warning message on PGTK.

[Stefan Monnier]

>> Fundamental to the implementation means that it can be fixed without
>> changing the design of the API ;-)
> I do see what you mean -- and please do suggest another word if you have
> one in mind -- but in this case I am not sure the distinction between
> fundamental-to-the-API and fundamental-to-the-implementation matters.

Maybe "difficult to fix"?


        Stefan

Re: master f0ff20be51: * src/emacs.c (main): Improve accuracy of daemon warning message on PGTK.

[Sean Whitton]

Hello,

On Thu 07 Apr 2022 at 07:04PM -04, Stefan Monnier wrote:

>>> Fundamental to the implementation means that it can be fixed without
>>> changing the design of the API ;-)
>> I do see what you mean -- and please do suggest another word if you have
>> one in mind -- but in this case I am not sure the distinction between
>> fundamental-to-the-API and fundamental-to-the-implementation matters.
>
> Maybe "difficult to fix"?

Cool, thanks, pushed that.

-- 
Sean Whitton

Re: master f0ff20be51: * src/emacs.c (main): Improve accuracy of daemon warning message on PGTK.

[Sean Whitton]

Hello,

On Thu 07 Apr 2022 at 09:09pm -07, Sean Whitton wrote:

> Cool, thanks, pushed that.

This was the first thing I've ever pushed myself, but it seems it didn't
make it to emacs-diffs.  Something DKIM-related?

-- 
Sean Whitton

Re: master f0ff20be51: * src/emacs.c (main): Improve accuracy of daemon warning message on PGTK.

[Eli Zaretskii]

> From: Sean Whitton <spwhitton@spwhitton.name>
> Date: Thu, 07 Apr 2022 22:29:20 -0700
> 
> Hello,
> 
> On Thu 07 Apr 2022 at 09:09pm -07, Sean Whitton wrote:
> 
> > Cool, thanks, pushed that.
> 
> This was the first thing I've ever pushed myself, but it seems it didn't
> make it to emacs-diffs.  Something DKIM-related?

No.  Emacs-diffs employs moderation.  So that's normal (for the first
time you install changes), and was already taken care of for your
case.

Re: master f0ff20be51: * src/emacs.c (main): Improve accuracy of daemon warning message on PGTK.

[Sean Whitton]

Hello,

On Fri 08 Apr 2022 at 09:13am +03, Eli Zaretskii wrote:

> No.  Emacs-diffs employs moderation.  So that's normal (for the first
> time you install changes), and was already taken care of for your
> case.

I see, thank you.

-- 
Sean Whitton