From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: chad Newsgroups: gmane.emacs.devel Subject: Re: Question about pgtk -- is it meant to fix the disconnect crash bug? Date: Thu, 4 Mar 2021 18:06:29 -0800 Message-ID: References: <87h7lr4zrv.fsf@melete.silentflame.com> <58148d31-5886-a684-5a8a-49d489fcf355@grinta.net> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000ef657405bcc0887d" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="39707"; mail-complaints-to="usenet@ciao.gmane.io" Cc: EMACS development team To: Daniele Nicolodi Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Mar 05 03:07:25 2021 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lHzsD-000AFT-2V for ged-emacs-devel@m.gmane-mx.org; Fri, 05 Mar 2021 03:07:25 +0100 Original-Received: from localhost ([::1]:48796 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lHzsC-00013P-1o for ged-emacs-devel@m.gmane-mx.org; Thu, 04 Mar 2021 21:07:24 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:45256) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lHzrc-0000dr-8k for emacs-devel@gnu.org; Thu, 04 Mar 2021 21:06:48 -0500 Original-Received: from mail-lj1-x22c.google.com ([2a00:1450:4864:20::22c]:45126) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lHzrW-0002Nm-Ov for emacs-devel@gnu.org; Thu, 04 Mar 2021 21:06:48 -0500 Original-Received: by mail-lj1-x22c.google.com with SMTP id y12so703376ljj.12 for ; Thu, 04 Mar 2021 18:06:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=zBfjSVhs2Ms5tj897iyUKubVW5Lm4jyKCdc9090aEqg=; b=fKoHOIkcoACF+JR3QGwHDEPsGuIzvAZghaGMqJGCdoNFwim1FF6eXbgVFMa+HD/Csh 1iOqfGEcwmBkJBjdaPkzjf6tSdZON8RJU/zR1rFHBFFt1Izt1dtssZ51Ds522o80fc9D FUH91vpWBdbWk+AyvYhkH9g3J0pvdrWLYRfFMnRCq14Tr/vG59c5uaEM80lEWMWyLiv7 JAToNMMBrjaEOnfwx3NikVZqqIor/rOpK0rJuCy68jkA4y9J0183MiY+QmgLcGwc11GY 5PcsQPRC88duNLpkHDKNKdMt8euZU08OMMampx2O0iXibfBznJDU8MnITSIWPUYoym+y Q5DQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=zBfjSVhs2Ms5tj897iyUKubVW5Lm4jyKCdc9090aEqg=; b=qVvmajxjrzb+rDx80yGaT6ev5+KvJeiX8o9peXJz3dS8feo6iR5QrUJIUDRftkyWky i8uwFiF46oOl8gDJA1hx1rpO/PaA7XK365syZM+jTcLL9/EIbSrHd15g2NNPIN2rG1vi K3ZnCUyl+/P8c2N+kVTETlU4DtH+5ivcGfC5GYltdqNVkBKz9++jGM04T4/Oy2hge6Cj SwauB07GxYfB+vmw2YfZzIWgQTJr6X7V1rjT3vvrtkOZhI9TJJuMjh1/VCqUQwZ6PQuU oTOoHqNV0D5ElcEtV+FBUIhepYl79WY4aKx9Me+kMRMLGg2ItEWA+dA8w4Fe6WsWp9j2 /vvw== X-Gm-Message-State: AOAM531KbhJaxNz6Ga22qA4rCh1vMmc2Xn/DTuSWowOzpJ1QWm5ww1F9 gsLzO3I0RpAHVThZ/HTuC0BGs/AQPgg56dP1w7I= X-Google-Smtp-Source: ABdhPJy77WeQFVOshs54jNiT4kV9QCDY9w33atOdk3TSl0KXVyKB2Lq0atZDi9FQwWlZUH7dG7QDfF1y39odh/ofEFs= X-Received: by 2002:a05:651c:118a:: with SMTP id w10mr3656119ljo.431.1614910000685; Thu, 04 Mar 2021 18:06:40 -0800 (PST) In-Reply-To: <58148d31-5886-a684-5a8a-49d489fcf355@grinta.net> Received-SPF: pass client-ip=2a00:1450:4864:20::22c; envelope-from=yandros@gmail.com; helo=mail-lj1-x22c.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:266000 Archived-At: --000000000000ef657405bcc0887d Content-Type: text/plain; charset="UTF-8" On Thu, Mar 4, 2021 at 2:58 PM Daniele Nicolodi wrote: > The last time I looked at this the GTK maintainers are interested in > investigating the bug and fixing it in GTK as long as it does not > involve debugging Emacs but a more manageable reproducer of the issue. > AFAIK, no one tried to provide one. > That actually does not match my understanding; if I remember correctly, the GTK people felt that emacs was doing something that they did not want to support, and since no "well behaved" GTK applications had reported the problem, they were thus were unwilling to continue. I might be misremembering. Also, the last time I looked, Emacs aborts() when it detects the > condition that causes the bug, thus fixing the bug in GTK does not > automatically fix Emacs. > Emacs added that code as a response to the GTK bug, because calling abort() itself is minorly cleaner than allowing the crash from _exit() in the library. At heart, emacs is trying to use a niche feature that was spec'd but never fully implemented in gtk/gdk. Nobody else wants to use that feature, because there just aren't that many apps that want to hop around between open and closed displays (like emacs --daemon does) AND that also have a lot of long-lived state (most would be fine with simply closing and restarting). Web browsers are the nearest candidate that comes to mind, and they have already invested large-to-massive effort in the alternative "run distinct copies everywhere, including your phone, and layer on a sync service for the few places where you might care". This creates an environment where the GTK maintainers weigh a bunch of groddy low-level work to support a feature almost no one wants on one side against a client base that has the highly-functional "just use Lucid" alternative on the other. This world doesn't produce a lot of motivation to solve the problem, and the solution will likely (if I understand the decade-plus-old bug-thread) require fairly low-level changes to gtk/gdk, so the solver needs to be very familiar with gdk internals, so the friction is quite high. In the meantime, X11 is due to be obsoleted every few years for the last decade... ~Chad --000000000000ef657405bcc0887d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, Mar 4, 2021 at 2:58 PM Daniel= e Nicolodi <daniele@grinta.net= > wrote:
The = last time I looked at this the GTK maintainers are interested in
investigating the bug and fixing it in GTK as long as it does not
involve debugging Emacs but a more manageable reproducer of the issue.
AFAIK, no one tried to provide one.

Tha= t actually does not match my understanding; if I remember correctly, the GT= K people felt that emacs was doing something that they did not want to supp= ort, and since no "well behaved" GTK applications had reported th= e problem, they were thus were unwilling to continue. I might be misremembe= ring.=C2=A0

Also, the last time I looked, Emacs aborts() when it detects the
condition that causes the bug, thus fixing the bug in GTK does not
automatically fix Emacs.

Emacs added th= at code as a response to the GTK bug, because calling abort() itself is min= orly cleaner than allowing the crash from _exit() in the library.=C2=A0

At heart, emacs is trying to use a niche feature that= was spec'd but never fully implemented in gtk/gdk. Nobody else wants t= o use that feature, because there just aren't that many apps that want = to hop around between open and closed displays (like emacs --daemon does) A= ND that also have a lot of long-lived state (most would be fine with simply= closing and restarting). Web browsers are the nearest candidate that comes= to mind, and they have already invested large-to-massive effort in the alt= ernative "run distinct copies everywhere, including your phone, and la= yer on a sync service for the few places where you might care".
<= div>
This creates an environment where the GTK maintainers we= igh a bunch of groddy low-level work to support a feature almost=C2=A0no on= e wants on one side against a client base that has the highly-functional &q= uot;just use Lucid" alternative on the other. This world doesn't p= roduce a lot of motivation to solve the problem, and the solution will like= ly (if I understand the decade-plus-old bug-thread) require fairly low-leve= l changes to gtk/gdk, so the solver needs to be very familiar with gdk inte= rnals, so the friction is quite high. In the meantime, X11 is due to be obs= oleted every few years for the last decade...

~Cha= d
--000000000000ef657405bcc0887d--