Hi,

I just built emacs 28 with the lasted source, and it seems that this bug
reappears.
Since I have not updated emacs for a long time, I am not sure when it came
back.
I checked xwidget.c and previous fix is still there.

The testing environment and the way to reproduce it is the same as before.

Hopefully someone can confirm this.
Thanks!


Akira Kyle <ak@akirakyle.com> 于2020年11月15日周日 上午3:53写道：

>
> On Sat, Nov 14, 2020 at 09:22 AM, Eli Zaretskii <eliz@gnu.org>
> wrote:
>
> >> > The attached patch fixes this but only in a temporary way.
> >>
> >> Thanks; applied to Emacs 28.
> >
> > Just to be sure: the fix that is now installed on master does
> > support
> > current and old versions of Glib, where the old code seemed to
> > work?
> > Or does it break with older Glib versions?
>
> I didn't explicitly try it with glib versions before they changed
> the signal handling in commit 2e471acf, but it *should* work with
> versions before the change. As you can see in the patch, it
> essentially just makes Emacs more aggressive in taking over the
> signal handler and in glib versions before 2e471acf,
> g_source_unref (source) wouldn't result in glib resetting the
> signal handler to SIG_DFL, in which case Emacs will just install
> itself twice to handle SIGCHLD which is fine.
>
> I think commit 2e471acf got added to glib with version 2.37.5
> which was released over 7 years ago.
>
>