X-Recipient: archive-cygwin@delorie.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@cygwin.com; run by ezmlm
List-Id: <cygwin.cygwin.com>
List-Subscribe: <mailto:cygwin-subscribe@cygwin.com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin@cygwin.com>
List-Help: <mailto:cygwin-help@cygwin.com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner@cygwin.com
Mail-Followup-To: cygwin@cygwin.com
Delivered-To: mailing list cygwin@cygwin.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@xs4all.nl>
Reply-To: cygwin@cygwin.com
To: cygwin@cygwin.com
Subject: Re: Regression (last snapshot)
References: <20190729134700.GO11632@calimero.vinschen.de> <ced2750a-0a52-1396-b6c1-f4228116bde7@cornell.edu> <20190729152327.GQ11632@calimero.vinschen.de> <20190729154049.GR11632@calimero.vinschen.de> <c5d01965-80b9-cece-54d2-f7462f84c0a2@cornell.edu> <8e57d4da-722d-1b9a-bd28-5f96ed182f6a@cornell.edu> <0a09679b-1a0f-613b-04c8-1a63da8a00c2@cornell.edu> <33aead20-540c-ee3b-0d38-ff053fbac040@dronecode.org.uk> <12269538-c387-1f1e-ab5a-b36b60d09937@cornell.edu> <a61264b5-80da-52fc-7093-8e8d9a8ace33@redhat.com> <20190801160440.GC11632@calimero.vinschen.de> <19e73527-cb9a-a106-a57a-2895b8a520c9@cornell.edu> <e922144a-1f02-9398-4223-dbf76c69231f@cornell.edu> <b4d57d88-3ec4-939f-c591-e50aaef607f3@cornell.edu>
In-Reply-to: <b4d57d88-3ec4-939f-c591-e50aaef607f3@cornell.edu>
Content-Type: text/plain; charset=UTF-8; format=fixed
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

