X-Recipient:	archive-cygwin AT delorie DOT com
DomainKey-Signature:	a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:date:message-id:from:reply-to:to:subject
	:references:in-reply-to:content-type; q=dns; s=default; b=Vrt5y3
	uktEsDQDjzb664xrEtA/F2i7NPMt/Nt483jKH9Gx1hCpz6TbdCt0LzTRntDJkF6u
	lVZryZd9Nf8P6rdux3BjpdafrnOTyga1mOPFHrAHbQa0KY8mokDkOngzAGKmRuXg
	r0IjTlG5u/9FYtOTyAYRWw5t6ZasbpXkrobgk=
DKIM-Signature:	v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:date:message-id:from:reply-to:to:subject
	:references:in-reply-to:content-type; s=default; bh=v4zNGBPdgmAd
	VZOkSTMzPvrSBr4=; b=UG/n65ihoSHNFhCZkKIkcQ8HPdnf/5xPl0N+X11nvBaE
	gateMaPVQSvCF6S0EmL+BddVpSB5DRQRpnQs1/4Qkzs8N6wvxP+OzrXqWGWHK741
	d1GrPuaVfs7M+LNKDBOdG9RuRGvAAI1RHW98qf2fRDc87kUSdWQ2cHm2oFxhf1s=
Mailing-List:	contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id:	<cygwin.cygwin.com>
List-Subscribe:	<mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive:	<http://sourceware.org/ml/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender:	cygwin-owner AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
Delivered-To:	mailing list cygwin AT cygwin DOT com
Authentication-Results:	sourceware.org; auth=none
X-Spam-SWARE-Status:	No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.1 spammy=H*F:D*nl, near
X-HELO:	lb1-smtp-cloud8.xs4all.net
Date:	Sun, 04 Aug 2019 18:52:30 +0200
Message-ID:	<c3b303b4a25b450d11001479309b1574@smtp-cloud8.xs4all.net>
From:	Houder <houder AT xs4all DOT nl>
Reply-To:	cygwin AT cygwin DOT com
To:	cygwin AT cygwin DOT com
Subject:	Re: Regression (last snapshot)
References:	<20190729134700 DOT GO11632 AT calimero DOT vinschen DOT de> <ced2750a-0a52-1396-b6c1-f4228116bde7 AT cornell DOT edu> <20190729152327 DOT GQ11632 AT calimero DOT vinschen DOT de> <20190729154049 DOT GR11632 AT calimero DOT vinschen DOT de> <c5d01965-80b9-cece-54d2-f7462f84c0a2 AT cornell DOT edu> <8e57d4da-722d-1b9a-bd28-5f96ed182f6a AT cornell DOT edu> <0a09679b-1a0f-613b-04c8-1a63da8a00c2 AT cornell DOT edu> <33aead20-540c-ee3b-0d38-ff053fbac040 AT dronecode DOT org DOT uk> <12269538-c387-1f1e-ab5a-b36b60d09937 AT cornell DOT edu> <a61264b5-80da-52fc-7093-8e8d9a8ace33 AT redhat DOT com> <20190801160440 DOT GC11632 AT calimero DOT vinschen DOT de> <19e73527-cb9a-a106-a57a-2895b8a520c9 AT cornell DOT edu> <e922144a-1f02-9398-4223-dbf76c69231f AT cornell DOT edu> <b4d57d88-3ec4-939f-c591-e50aaef607f3 AT cornell DOT edu>
In-Reply-to:	<b4d57d88-3ec4-939f-c591-e50aaef607f3@cornell.edu>
User-Agent:	mua.awk 0.99

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()?

Another option?

 - 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:
# 
# http://hackage.haskell.org/trac/ghc/ticket/4274

Installing the empty handler after the call to gtk_init() ...

Henri


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

- Raw text -