This is the mail archive of the
mailing list for the Cygwin project.
Re: Regression (last snapshot)
On Fri, 2 Aug 2019 14:34:02, Ken Brown wrote:
> I think I've finally got it.
> First of all, here's what POSIX says about signal handlers after an exec:
> "Signals set to the default action (SIG_DFL) in the calling process
> image shall be set to the default action in the new process image.
> Except for SIGCHLD, signals set to be ignored (SIG_IGN) by the calling
> process image shall be set to be ignored by the new process image.
> Signals set to be caught by the calling process image shall be set to
> the default action in the new process image (see <signal.h>)."
> Second, here's a quote from the GTK+ documentation for gtk_init():
> "Since 2.18, GTK+ calls signal (SIGPIPE, SIG_IGN) during initialization,
> to ignore SIGPIPE signals, since these are almost never wanted in
> graphical applications. If you do need to handle SIGPIPE for some
> reason, reset the handler after gtk_init(), but notice that other
> libraries (e.g. libdbus or gvfs) might do similar things."
> Third, xwin-xdg-menu calls gtk_init() near the beginning of main().
> Putting this all together, Eric's explanation is indeed correct. All
> processes created by xwin-xdg-menu via fork/exec inherit the property of
> ignoring SIGPIPE.
> I don't know if this is a bug, but it certainly leads to surprising
> behavior. Jon, maybe xwin-xdg-menu needs to call signal(SIGPIPE,
> SIG_DFL) either after calling gtk_init() or before calling exec()?
- https://bugs.python.org/issue1652 - see msg115364 (Author: Mitar)
# GHC Haskell compiler is currently opting for a different solution:
# installing an default empty handler which is cleared by exec
# automatically and signal handler is restored back to SIG_DFL:
Installing the empty handler after the call to gtk_init() ...
Problem reports: http://cygwin.com/problems.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple