In GNU Emacs 29.0.50 (build 1, aarch64-unknown-linux-gnu, GTK+ Version 3.24.30, cairo version 1.16.0) Repository revision: ab5ee3e29e916d4009b301841e9780aad564a6a0 Repository branch: master System Description: NixOS 22.05 (Quokka) Configured using: 'configure --prefix=/nix/store/0fiqa453abl4c1c28g0baqs9s274s7ff-emacs-pgtkgcc-20220103.0 --disable-build-details --with-modules --with-x-toolkit=gtk3 --with-cairo --with-xwidgets --with-native-compilation --with-pgtk' Also tested on debian under GNOME (wayland) with the same configuration. Steps to reproduce in emacs -Q: - M-x xwidget-webkit-browse-url RET http://xkcd.com RET - C-x k RET - M-: (start-process "my-process" "foo" "echo" "hi") No "Process my-process finished" line appears in buffer "foo" indicating that emacs didn't catch SIGCHLD. I suspect that a call to catch_child_signal might also be needed in kill_xwidget so emacs reinstalls its signal handler.
Akira Kyle <akira@akirakyle.com> writes:
> I suspect that a call to catch_child_signal might also be needed in
> kill_xwidget so emacs reinstalls its signal handler.
Should be fixed now on master.
Making kill_xwidget call catch_child_signal wasn't enough, since GLib
was resetting SIGCHLD inside a timer set by WebKitGTK and about a dozen
other places as well, hence the very ugly (and unreliable) hack on
master.
It's a temporary solution that just motivated me to look at making Emacs
use GLib for handling subprocesses.
On Tue, Jan 4, 2022 at 7:40 PM Po Lu <luangruo@yahoo.com> wrote: > > > I suspect that a call to catch_child_signal might also be needed in > > kill_xwidget so emacs reinstalls its signal handler. > > Should be fixed now on master. > It looks like SIGCHLD is now being caught by emacs for me. Thanks! > Making kill_xwidget call catch_child_signal wasn't enough, since GLib > was resetting SIGCHLD inside a timer set by WebKitGTK and about a dozen > other places as well, hence the very ugly (and unreliable) hack on > master. > > It's a temporary solution that just motivated me to look at making Emacs > use GLib for handling subprocesses. Indeed GLib does appear to want to always own the signal handling and I imagine the current hacks of trying to constantly reinstall the handler are also potentially brittle solutions to the problem.
[[[ To any NSA and FBI agents reading my email: please consider ]]] [[[ whether defending the US Constitution against all enemies, ]]] [[[ foreign or domestic, requires you to follow Snowden's example. ]]] Emacs does a lot of special things in handling subprocesses, and that is a very important feature. On general principles, I think that means we should perfect our own code rather than try to use code maintained by another project for this. -- Dr Richard Stallman (https://stallman.org) Chief GNUisance of the GNU Project (https://gnu.org) Founder, Free Software Foundation (https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org)
Richard Stallman <rms@gnu.org> writes:
> Emacs does a lot of special things in handling subprocesses, and that
> is a very important feature.
>
> On general principles, I think that means we should perfect our own
> code rather than try to use code maintained by another project for
> this.
I'm not talking about replacing Emacs's own code with GLib's system
entirely, but just relying on GLib to tell us when a process exits,
instead of installing our own SIGCHLD handler.
Thanks.
[[[ To any NSA and FBI agents reading my email: please consider ]]] [[[ whether defending the US Constitution against all enemies, ]]] [[[ foreign or domestic, requires you to follow Snowden's example. ]]] > I'm not talking about replacing Emacs's own code with GLib's system > entirely, but just relying on GLib to tell us when a process exits, > instead of installing our own SIGCHLD handler. I don't know enough to have an opinion in detail, but on general principles I suggest that we fix our own code. Depending on an external package for little bits of Emacs is asking for trouble. Our code can have bugs, and the Glib code can have bugs, but if our code has bugs, there is no obstacle to our using a fixed version. -- Dr Richard Stallman (https://stallman.org) Chief GNUisance of the GNU Project (https://gnu.org) Founder, Free Software Foundation (https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org)
Richard Stallman <rms@gnu.org> writes:
> I don't know enough to have an opinion in detail, but on general
> principles I suggest that we fix our own code. Depending on an
> external package for little bits of Emacs is asking for trouble. Our
> code can have bugs, and the Glib code can have bugs, but if our
> code has bugs, there is no obstacle to our using a fixed version.
I'm only proposing to use GLib's code in Emacs builds that have GLib.
(Those which use GTK+, for example, must have GLib.)
The reason is that GLib resets the Emacs SIGCHLD handler at random
spots, which is very difficult to work around.
Thanks.
[[[ To any NSA and FBI agents reading my email: please consider ]]] [[[ whether defending the US Constitution against all enemies, ]]] [[[ foreign or domestic, requires you to follow Snowden's example. ]]] > I'm only proposing to use GLib's code in Emacs builds that have GLib. > (Those which use GTK+, for example, must have GLib.) Maybe you're right. I am no expert on this so I will leave it to others. -- Dr Richard Stallman (https://stallman.org) Chief GNUisance of the GNU Project (https://gnu.org) Founder, Free Software Foundation (https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org)
Akira Kyle <akira@akirakyle.com> writes: > It looks like SIGCHLD is now being caught by emacs for me. Thanks! I'm therefore closing this bug report. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no
Po Lu <luangruo@yahoo.com> writes: > It's a temporary solution that just motivated me to look at making Emacs > use GLib for handling subprocesses. I think that's certainly worth a try -- we've had a lot of these issues over the years. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no