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:from:to:subject:message-id:reply-to
	:references:mime-version:content-type:in-reply-to; q=dns; s=
	default; b=sqd/KIGWvw2F+7tncd6FS81H78N9ETJ4In4uPArPa3dxncScG5d8w
	nk1pUPGGdDFRlM0NTZIWKrXmA1OjWK+2249l/Mx27SZ91kPJ5gaUR80B2OQk0cp/
	sMpszHoM40V9L5ay2JAlCOSWat0hIe6Lj/eNHfURBTryx4Paby/PtE=
Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm
Sender: cygwin-owner@cygwin.com
Mail-Followup-To: cygwin@cygwin.com
Date: Wed, 3 Apr 2019 14:43:31 +0200
From: Corinna Vinschen <corinna-cygwin@cygwin.com>
To: cygwin@cygwin.com
Subject: Re: uc_sigmask set in a sigaction signal handler not honored
Message-ID: <20190403124331.GZ3337@calimero.vinschen.de>
Reply-To: cygwin@cygwin.com
Mail-Followup-To: cygwin@cygwin.com
References: <366918d8-b505-45be-dc28-303579f17341@gmail.com> <20190403121555.GV3337@calimero.vinschen.de>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;	protocol="application/pgp-signature"; boundary="3pZQ0wszfDg7ZRO+"
Content-Disposition: inline
In-Reply-To: <20190403121555.GV3337@calimero.vinschen.de>
User-Agent: Mutt/1.11.3 (2019-02-01)

--3pZQ0wszfDg7ZRO+
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Apr  3 14:15, Corinna Vinschen wrote:
> On Apr  3 11:27, Petr Sko=C4=8D=C3=ADk wrote:
> > Hi. Correct me if I'm wrong but POSIX appears to define
> >=20
> > https://pubs.opengroup.org/onlinepubs/7908799/xsh/ucontext.h.html
> >=20
> > as, among other things, containing the field:
> >=20
> > sigset_t    uc_sigmask  the set of signals that are blocked when this
> >                         context is active
> >=20
> > and it also specifies that the third argument to a .sa_sigaction
> > signal handler is a ucontext_t* cast to void*.
> >=20
> > So it should follow that doing
> >=20
> > void act(int Sig, siginfo_t *Info, void *Uctx)
> > {
> > 	ucontext_t *uctx =3D Uctx;
> > 	sigfillset(&uctx->uc_sigmask);
> > }
> >=20
> > from a signal handler should alter the signal mask of the thread the
> > signal ran on.
> >=20
> > This is how Linux and MacOS behave, but not CygWin, as the following
> > program shows:
>=20
> What you're asking for is really complicated.
>=20
> The context given to act is the context at the time the signal function
> is called.  In Cygwin (lower case w) this is a copy of the context.
>=20
> sigfillset() has not the faintest clue where this context comes from, it
> just sets the signal mask value without taking any further action.
>=20
> There are no provisions to control if the called function changes the
> context, other than via setcontext / swapcontext, and I don't see that
> POSIX requires anything else.  Both functions change the current
> thread's sigmask according to the value of uc_sigmask.

Or maybe I'm just dumb.  Would it suffice if the thread's signal mask is
changed to uc_sigmask when the signal function returns?


Corinna

--=20
Corinna Vinschen
Cygwin Maintainer

--3pZQ0wszfDg7ZRO+
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEoVYPmneWZnwT6kwF9TYGna5ET6AFAlykqnMACgkQ9TYGna5E
T6CxEQ//YNE7RWusmx1aqcLcyQWMgyKTu+yl1L72CZ7Qxlc1pon8O0q4rJ2mo9z1
55r+dX+PBNGKKFjGfya7qaLmHTIthSrGNCSvj/Eyq+N3K5M1SRJgQ9/zWlH9GbyZ
HYjmGEZkwYUEyxSYfqfkduIU7SCmAU2pBV/wplEsHRNgrkJQkqDKYrhk3Tk23Vnb
qx5BzmcFjp0rbLoGo9qhTdKxNsqhmmTEtyeH8kWWq3wtiD9hUT5PWfiku62THOJq
l2mGWUVsR1ilOsPaVrlaBhctthfknSANvVh3PrUMxU4eAmH+gm8f/oWBTUXoxM0Z
mJOwOkjw7QPpKbaR1G++DSA0XudMrMZGqOcm8FomSkCwcwUNvH5YoLhPvCqIj8xa
Pf8a8ewbkPgecerwhIbNvudYuCCbWW34NKZ5iGXZnP0GuZPCGEkPAf3IWKIDo0N/
kB7SwU7WWLzfKRuyUYVasAQMI7q8WkNyRDJ0LXrUC9JBvngzEpA8vW0Ogt3Cs8s9
KCp657ggXdt/E3EQhEt0k/MveOFyVGtYKfoo9taKKIM2pXL7nhZV6UnrQG0hNcih
w9LzpSfmaUfN4PrkOISeq9kVgnU0Mse23GYQvlml2j8/pqIQZhaOHKZbuEs4L3X/
ehI3K9XdJuGmpG7FxeYDdVeVUYcJ4aZom4DDVClYlqvnue62TJo=
=4yKT
-----END PGP SIGNATURE-----

--3pZQ0wszfDg7ZRO+--