Date: Fri, 1 Jun 2012 17:08:27 -0500
From: "Ryan C. Underwood" <nemesis-lists@icequake.net>
To: cygwin@cygwin.com
Subject: Re: How to "bisect" Cygwin?
Message-ID: <20120601220827.GG25227@localhost.localdomain>
Reply-To: nemesis@icequake.net
References: <20120531210143.GA11744@localhost.localdomain> <20120601174610.GD25227@localhost.localdomain> <20120601181852.GF28506@calimero.vinschen.de> <20120601184041.GE25227@localhost.localdomain> <20120601185906.GG28506@calimero.vinschen.de> <20120601195107.GF25227@localhost.localdomain> <4FC9391B.3040104@etr-usa.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;	protocol="application/pgp-signature"; boundary="XRI2XbIfl/05pQwm"
Content-Disposition: inline
In-Reply-To: <4FC9391B.3040104@etr-usa.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm
Precedence: bulk
Sender: cygwin-owner@cygwin.com
Mail-Followup-To: cygwin@cygwin.com

--XRI2XbIfl/05pQwm
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Fri, Jun 01, 2012 at 03:50:19PM -0600, Warren Young wrote:
> >
> >The basic issue is that sem_wait() is being kicked out with EINTR
> >extremely frequently (9 out of 10 times or more),
>=20
> Does the attached program vaguely resemble what your program is
> trying to do?  It does get EINTR, but only because I'm using
> alarm(2) to add a timeout to the sem_wait() call.

Yes.  In fact it is very close but with a significant difference.

My (inherited) program is using setitimer() as a master timer, and I
am not sure that the signals are being masked correctly per thread.
In fact, the code is a real mess, but what I have observed is that
with 1.7.9, the SIGALRM which was set by thread 1 does not interrupt
thread 2's sem_wait() system call, but with 1.7.10, the SIGALRM does
interrupt thread 2 (but without delivering the SIGALRM to thread 2,
apparently?  Need to test some more)

Basically, I was hoping to dig down and find some significant changes
in the way signals and threads interact from the 'working' Cygwin to
the 'non-working', which would convince me that I really need to get
to rewriting this stuff if the current Cygwin is considered to be
proper in that respect.  I also wanted to ensure that a bug had not
crept in to Cygwin that would hammer other people with legacy code.

Thanks,

--=20
Ryan C. Underwood, <nemesis@icequake.net>

--XRI2XbIfl/05pQwm
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iD8DBQFPyT1bIonHnh+67jkRAhgnAJ9EDjlzK/XgR8AEXnnOFPnUo3h4gACcCPn/
hBXUM+9y6YOeLo4awzPUn4Q=
=jHtq
-----END PGP SIGNATURE-----

--XRI2XbIfl/05pQwm--