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=iyvDRHVEBc1R/DvWg+gdHpbNNASp4rNynVRROoKZ+1eOx7EcmL1P2
	vEFZZP2DWiJutLvNXEcPtZJutPYxnbTv7n6g9sXoJOMYDVx9HC+ideTQ5dYLgPE4
	gRUcVQLa5EtF/1qfz9hHzUpFDLt/NYJ/4xKusf0H0CdAg7XnwVe1WA=
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=O5QE3xg58Fj1SyDD8iBIUQKQ7hY=; b=bA4FH4IVHXXCM46eV+d3W97wVMU1
	MSSH8PatnFaBVC60LlNDWxozic211QrFuO/OvHtXrsPkU6EsRR9GNflVXm39O6uM
	eZbw2fzO49JEMWJEzxb2hswBXpEPKBE/9ciPVQDFXpkSbhCQ5ZmJNneofEwYtAdh
	wcs8L+AV0v80+18=
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 11:38:42 +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:	<20150119103842.GD10055@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>
MIME-Version:	1.0
In-Reply-To:	<6E8492D726F2EA4D8D5418F55704603F01028679FF24@THSONEP02CMB02P.one-02-priv.grp>
User-Agent:	Mutt/1.5.23 (2014-03-12)

--2iBwrppp/7QCDedR
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Jan 19 08:29, SCOTT Damien wrote:
> I have a multi-threaded process running under Cygwin that receives
> messages from several IPC message queues (built using Cygwin's gcc,
> version 4.8.3).=C2=A0 The listener for each queue runs in its own thread,
> each of which is created from the main thread.=C2=A0 Each listener is usi=
ng
> a blocking call to msgrcv().=C2=A0 I want the main thread to be able to u=
se
> pthread_kill() to send a SIGUSR1 signal to each listening thread to
> cause it to abandon its call to msgrcv() and then exit.=C2=A0=20
>=20
> My approach has been to create a signal mask containing just SIGUSR1
> and associate this with a signal handler (although the signal handler
> contains no functionality, since all I need is for the blocking call
> to msgrcv() to be abandoned).=C2=A0 I initially set the signal mask to
> block in the main thread, which should then be inherited by each of
> the created listening threads.=C2=A0 I only unblock the signal mask around
> the call to msgrcv() in each listening thread.
>=20
> 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 change 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 sleep
> 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.

It's an issue with the Cygwin code, probably.  The msgrcv code ultimately
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.

For the time being, would it be much of a problem for you to convert
your stuff to POSIX message queues(*)?  These don't require running
cygserver, and they are supposed not to suffer from this problem.
Fixing them in case of a bug is much easier as well.


Corinna

(*) http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/mqueue.h.html

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

--2iBwrppp/7QCDedR
Content-Type: application/pgp-signature

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

iQIcBAEBAgAGBQJUvN6yAAoJEPU2Bp2uRE+gKisP/1bGCLrEpzNvU3umg4O7ZM4r
RS1DyHriWY4098LjVFXmbbyGLZ1JaFKu85xSkGLQC7CraifzEnPBPeRlR9CDjM40
B1Hy6cBWVqx+qgtHhMFkYNQpfwYMmCuhN56KYQlHqeBIXdbjdPzKz0DYjlrqpUb0
fTKR6gO43qniVtxBL961TkS0RfbMANeXGkhhA7TR3hEncOzzZJ/uGsAF6xAhh5xn
TnEkZO6tGmSbkuV3Cn0Q4hZsY1StSuFiYe7TpOGnrezJ3oXxLplv47RZN7z8dzV/
3Sb7IXVAQzCD+xgUbB5ViRkqP/PfwJWO3pCtlTXQketVhNmJ9uPUta0jCOx15cFS
t3JYEDzYCOkBtfhB4Ut1//0Vqwu0F+E175UHmBj4nO8+fT14BTuMnLHkOV2xcd3M
y1CMd7IChm+RwqiRf8FnhsuV7/0JcmUUVF3ZN+usjcpLO6qv1xxBo0cRNRwmbQfU
bJymoyKnae4ekJVoOuUkAbZuY/jFfquJKKk8pUc0G+fKSgGwN0g5n6YcQFHOvq6a
E8f9g1BeiEB/YuYs52eOzlXZYKMjrKNlTWjd09ueV+I3vhBsnedOGgteADBmYAnT
29q84AhMgc13qPzC2p1DUFFAKFO3vBiDjQvMWM1HN9H95arjp4PesnJmPI2OzTKu
JfH8z980Csp+J51xqDs7
=LNqP
-----END PGP SIGNATURE-----

--2iBwrppp/7QCDedR--

- Raw text -