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:from:to:cc:subject:message-id:reply-to
	:references:mime-version:content-type:in-reply-to; q=dns; s=
	default; b=sCrLjxHz3i7Qgm+RFBcjQyvUlMIVZJhiY3QBhOZkqfYs6RMT6fcAi
	hQPl6/kW7TIQNPeUoGSvDCbZoEisIjR0lwkUNtb5i4iJFoHPh+Ym2NHboJjkKTtE
	Q4wo05bUgogKMaQCyrZdxRKAmJZOOCC/2vRpH0gYWV60K3PNmu/pZ0=
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:from:to:cc:subject:message-id:reply-to
	:references:mime-version:content-type:in-reply-to; s=default;
	bh=SbKwOk8hp8br2XuZA6fArYBupBA=; b=t+UjhDpxfAq/LCTH+cYcl2loNu6Y
	W+wVhGCdWiOifSvDUyyOLGuOUKPANUgvB+wFrMDeZHZofZxAus3IC9quBdNHhOkq
	ykKKbaSpZITPy5oUXb3p8Avl5ui2R8Qc1ec1V0guGtwSZNfL9/mMmdFwj+km/mEL
	bbr2FbJin6iexhs=
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=-101.8 required=5.0 tests=AWL,BAYES_00,GOOD_FROM_CORINNA_CYGWIN,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 spammy=k, snapshots, H*F:D*cygwin.com, act
X-HELO:	mout.kundenserver.de
Date:	Wed, 3 Apr 2019 18:29:20 +0200
From:	Corinna Vinschen <corinna-cygwin AT cygwin DOT com>
To:	Petr =?utf-8?B?U2tvxI3DrWs=?= <pskocik AT gmail DOT com>
Cc:	cygwin AT cygwin DOT com
Subject:	Re: uc_sigmask set in a sigaction signal handler not honored
Message-ID:	<20190403162920.GF3337@calimero.vinschen.de>
Reply-To:	cygwin AT cygwin DOT com
Mail-Followup-To:	Petr =?utf-8?B?U2tvxI3DrWs=?= <pskocik AT gmail DOT com>, cygwin AT cygwin DOT com
References:	<a63809a2-f284-a4f7-d83b-6472e488000b AT gmail DOT com>
MIME-Version:	1.0
In-Reply-To:	<a63809a2-f284-a4f7-d83b-6472e488000b@gmail.com>
User-Agent:	Mutt/1.11.3 (2019-02-01)

--PjLo8P/CG6vpADRe
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Apr  3 16:39, Petr Sko=C4=8D=C3=ADk wrote:
> > 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
> > > >
> > > > https://pubs.opengroup.org/onlinepubs/7908799/xsh/ucontext.h.html
> > > >
> > > > as, among other things, containing the field:
> > > >
> > > > sigset_t    uc_sigmask  the set of signals that are blocked when th=
is
> > > >                         context is active
> > > >
> > > > and it also specifies that the third argument to a .sa_sigaction
> > > > signal handler is a ucontext_t* cast to void*.
> > > >
> > > > So it should follow that doing
> > > >
> > > > void act(int Sig, siginfo_t *Info, void *Uctx)
> > > > {
> > > > 	ucontext_t *uctx =3D Uctx;
> > > > 	sigfillset(&uctx->uc_sigmask);
> > > > }
> > > >
> > > > from a signal handler should alter the signal mask of the thread the
> > > > signal ran on.
> > > >
> > > > This is how Linux and MacOS behave, but not CygWin, as the following
> > > > program shows:
> > >
> > > What you're asking for is really complicated.
> > >
> > > The context given to act is the context at the time the signal functi=
on
> > > is called.  In Cygwin (lower case w) this is a copy of the context.
> > >
> > > sigfillset() has not the faintest clue where this context comes from,=
 it
> > > just sets the signal mask value without taking any further action.
> > >
> > > 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?
>=20
> Thanks for the feedback.
>=20
> > Would it suffice if the thread's signal mask is
> > changed to uc_sigmask when the signal function returns?
>=20
> That is the idea. It's what Linux and MacOS do.

I pushed a patch which, for now, only sets the thread's sigmask to the
value set by the signal handler in uc_sigmask.

I have code in the loop allowing the signal handler to change the entire
context.  The code the signal handler returns to would check if the
handler changed the context and call setcontext if so.  However, I'm
reluctant to push it without having some serious, simple testcase.

As for restoring the thread signal mask, I uploaded new developer
snapshots to https://cygwin.com/snapshots/ for testing.  Please give
them a try.


Thanks,
Corinna

--=20
Corinna Vinschen
Cygwin Maintainer

--PjLo8P/CG6vpADRe
Content-Type: application/pgp-signature; name="signature.asc"

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

iQIzBAEBCAAdFiEEoVYPmneWZnwT6kwF9TYGna5ET6AFAlyk32AACgkQ9TYGna5E
T6CDxRAAopVmUMC9ipko0AsE8ZV2XXoFbzru6hNHI6+xCNeW4hFMu03+rd86Fmth
Mv4oxAgDvdIXoYZcohif1roR+AtLzMR+fDo0EMx3eHTPM1AnWadw6T05ZyyJg83M
18L5AwKlHow8bn4KeFylU9EBRa39LjDQvqOxbBGu4cSi0TlPqOj0YC5+BO6VeHT3
VYjiev4LD2bQK6fOIjBY1l/sVNEutpBqQoBU71X4PNEf4OL0PkxDM9YGscovrZnB
llLHkAN+D3VnYqAUBcCDmCQfDVINDaOaVDvXXA0PoaFvCmyBzcUm1CZRo95EIRSA
JHjo//epmLvW5nnpGOOXyuKvFYMTf62cFORcGqRT5y+zafcIVEw/XQO97O1hQdMY
spRhmhwEyBbUMDcAgFfodPda3ZsV44ttIpNX6mWiwyN7NM7zuVZWTTG97JustPrK
1yPMCWZ5LZhXYryjvHTdGBE1ygPBED1LV0XSg7T3CQOLf+YwB5PuZHf8lQu82viQ
iY/ckr8Wk6VHjsmsZtgwX+32BkO5ry7w4cRRT9Tla/y3w49yaOVB4iOkN3rlBNkn
mHKIPem/MWgB0wip7Ztf1oiowVbqvALR6eIilZX1Z/sRy6dmvekRtIKYI1nJwYys
9AZ/nYNCPHv/tMNdeL079uWqYvpQVRhUJkBkAXteGmtDoJyppXY=
=xAin
-----END PGP SIGNATURE-----

--PjLo8P/CG6vpADRe--

- Raw text -