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:subject:message-id:reply-to
	:references:mime-version:content-type:in-reply-to; q=dns; s=
	default; b=Ev1J/a4AgYl7L/XjfL7UGAVs5h1xA9BR8YcS+tHFjKKtcj1ITa+A1
	Qp8UVa2OrHCxSgd1vS3fmelI3XTJQNBEixgGspxai1cVi++2+H0hLg+HLr4RkSWT
	ISsvHQBkMLqjMZkK3xgy22UNS04B6RIBctXJ0d/ZeMWXfC1ispsiDU=
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:subject:message-id:reply-to
	:references:mime-version:content-type:in-reply-to; s=default;
	 bh=etkDj0u0ez8RfPNmADVZ4qewqcI=; b=YfrVOxJ79LibAfNf+ogAYyBV3XaQ
	VajpOxHKeAXpLavjb8fH0q9N+9J1lUP1dKLmPBK1wYNSSWZj1S+f/UmXNYYr9NoO
	6oHs6AF5cFTQKz0xThZShT8wAEgy5JA17v8EChoWoVHB+ovkQjxQ/cSkJPMPkLuS
	VzGx375h9kQ72Dg=
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-Virus-Found: No
X-Spam-SWARE-Status: No, score=-5.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.2
X-HELO: calimero.vinschen.de
Date: Mon, 19 Jan 2015 20:10:00 +0100
From: Corinna Vinschen <corinna-cygwin AT cygwin DOT com>
To: cygwin AT cygwin DOT com
Subject: Re: Using signals to unblock calls to msgrcv() in a multi-threaded process (Cygwin v1.7.33)
Message-ID: <20150119191000.GT3122@calimero.vinschen.de>
Reply-To: cygwin AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
References: <6E8492D726F2EA4D8D5418F55704603F01028679FF24 AT THSONEP02CMB02P DOT one-02-priv DOT grp> <20150119103842 DOT GD10055 AT calimero DOT vinschen DOT de> <20150119162105 DOT GR3122 AT calimero DOT vinschen DOT de>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;	protocol="application/pgp-signature"; boundary="l7GkBbkEatsaRqBf"
Content-Disposition: inline
In-Reply-To: <20150119162105.GR3122@calimero.vinschen.de>
User-Agent: Mutt/1.5.23 (2014-03-12)

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

On Jan 19 17:21, Corinna Vinschen wrote:
> On Jan 19 11:38, Corinna Vinschen wrote:
> > On Jan 19 08:29, SCOTT Damien wrote:
> > > [...]
> > > I have included a simplified version of my code below.=C2=A0 I usually
> > > don't see any evidence of the SIGUSR1 signal being received by either
> > > of the listener threads.=C2=A0 Occasionally the first thread unblocks=
 as
> > > expected but I have never seen both threads unblock.=C2=A0 If I chang=
e my
> > > code so that there is only a single listener thread, then everything
> > > works correctly every time.=C2=A0 Changing the msgrcv() call to a sle=
ep
> > > call also allows unblocking to occur correctly.=C2=A0 Note that this
> > > simplified code does not include removal of the created queues (since
> > > it never manages to exit anyway) so I manually remove these after each
> > > run using the ipcrm command.
> > >=20
> > > Example output:
> > >=20
> > > Running thread 2 with queue Id =3D 1441792
> > > Running thread 1 with queue Id =3D 1179649
> > > About to kill thread 1
> > >=20
> > > Is there an issue with the Cygwin implementation of signal handling,
> > > or is there a problem with my code?=C2=A0 Any help would be much
> > > appreciated.
> >=20
> > It's an issue with the Cygwin code, probably.  The msgrcv code ultimate=
ly
> > hangs in a blocking ReadFile call on a named pipe, and this call is
> > non-interruptible.  Changing that requires a bigger change in Cygwin
> > which will take time.
>=20
> ...or not.  I'm not sure I can fix that for the upcoming 1.7.34 release,
> but it seems cygserver is using the wrong signal handle.  At one point
> the signal handling got changed a lot to improve per-thread signalling,
> and, as far as I can see, the cygserver code still assumes a global
> per-process signal handle, which is the old version from before the
> change.
>=20
> Just to let you know I'm looking into that.  Stay tuned.
>=20
> Oh, btw., there's a bug in your testcase:
>=20
>   int id =3D msgget(key, IPC_CREAT|IPC_EXCL);
>=20
> This call is missing the permission bits, so the permissions are set
> to 000.  The permission bits should be added:
>=20
>   int id =3D msgget(key, IPC_CREAT|IPC_EXCL|S_IWUSR|S_IRUSR);

Well, it was not as complicated as I anticipated.  I applied a patch
to cygserver to pull it into the wonderful modern times of per-thread
signalling.  I created and uploaded a new developer snapshot to
https://cygwin.com/snapshots/ with this change.

Please give it a try and report back.


Thanks,
Corinna

--=20
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

--l7GkBbkEatsaRqBf
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBAgAGBQJUvVaIAAoJEPU2Bp2uRE+glmgP/jB6iZBVUc78D/7p3Edo1Bac
ODoamYn/7uwmKqEUIx7U8sqZsgkj3YZb0n+BkCH72KAIKRJOQ3RhvV1e0Z6QzzLO
eK/+vKXaBnxzcJBLUaF4QsIcg/LJyxpSvscTas5IpgjB7MZ3Tt6SD4mG6VOPdMiO
ig6XS/WG1XCe+7jsg0ymN8bByrNAwkBtvUKFTZvy0DS5vJ2TgvqCX4PPivehYAtI
IJ8HlezP+h4YH7UldL4AJbtyoqarZRHj/qHVSntD0YENCLCzt3ZNk3BQwqgLi+a/
LmV9DiPw5v7DMnWbTGkGV5HKgMaKbgNjOveVCABu2yXJ1CkTkdE7OtemZmm2iQA7
xfKJvP2RRLRfTKm5VCvVvHrEmS+bg89Nzhv+RyjAG4vYgh8/p0K3/f71i9tv6PXr
3T0TfixYTlBOZJFHcTJPolYH+AvjGkBRGzovn8LVwXeFfGIxVszaAf3igsIROMN1
TkqHOtQlGaOdTEiBt+Fjmd283Lxkdk5Sa4Vs7ysV220q9p+SQNx66zbTgerH5s4O
4CZKPap4gRUd0SDoMXbmhqd0oMgEN88P8MYiqkwAK7ZO38nDDkYB6sVWn3Ej0aCI
rHD4/Y674dPMlx5+P8CirxJS+UAr3rSFArnXo9BYic0geQq/tvQTKwvdt+oad2mm
xnb4a1bzwC8TIDafxNYD
=c4T8
-----END PGP SIGNATURE-----

--l7GkBbkEatsaRqBf--