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: List-Subscribe: List-Archive: List-Post: List-Help: , 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 To: Petr =?utf-8?B?U2tvxI3DrWs=?= 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=?= , cygwin AT cygwin DOT com References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="PjLo8P/CG6vpADRe" Content-Disposition: inline In-Reply-To: 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--