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=QbKug7IasWw4GTocjQSe8FnBnhFysgiVmuPT3oWOcyATq4pN/+byl
	6FrDIhbvIIG8Gqid9Naq8RZSPj5lKCRB564aZJomPFfNzbhN3TGuA68xjQG1gixx
	ZEmE5eJhLCgePFeccn4D6UHMJkzjObAwEPoH32v1NgDTDwI8JUxwZo=
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=0lf7yDueU7BHyM8X1P59nwIwWVg=; b=O19X+3V59l7dlAFzw15A3CftMJY8
	QyTtN0vWFUk6uARrEQZ7+3khziDBIM8022vml/M6/tEzAsoVzth+17sUSE4r9tNp
	hehuUEFAkEo9htP9vdeekmxYJvJ1noRerSv9ORCJkYnF+qWDH7xr2+x0bgIau63V
	Cb0L3E1aWmgjNUg=
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=-101.8 required=5.0 tests=AWL,BAYES_00,GOOD_FROM_CORINNA_CYGWIN,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_LOW,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=million, H*f:sk:ffa36cc, H*MI:sk:ffa36cc, H*i:sk:ffa36cc
X-HELO: drew.franken.de
Date: Sat, 25 Mar 2017 12:30:11 +0100
From: Corinna Vinschen <corinna-cygwin AT cygwin DOT com>
To: cygwin AT cygwin DOT com
Subject: Re: cygserver - Postgres Multiple connection Load Testing - Inifinte Loop
Message-ID: <20170325113011.GM29995@calimero.vinschen.de>
Reply-To: cygwin AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
References: <200408030333 DOT i733XEXn023894 AT mx3 DOT redhat DOT com> <20040803100612 DOT GP31522 AT cygbert DOT vinschen DOT de> <20170321025614 DOT GA2100214 AT tornado DOT leadboat DOT com> <20170324171101 DOT GI29995 AT calimero DOT vinschen DOT de> <ffa36cc6-a875-aad2-4a63-4ba7408f2ace AT gmail DOT com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;	protocol="application/pgp-signature"; boundary="IiVenqGWf+H9Y6IX"
Content-Disposition: inline
In-Reply-To: <ffa36cc6-a875-aad2-4a63-4ba7408f2ace@gmail.com>
User-Agent: Mutt/1.8.0 (2017-02-23)

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

On Mar 25 09:09, Marco Atzeri wrote:
> On 24/03/2017 18:11, Corinna Vinschen wrote:
> > Hi Noah,
> >=20
>=20
> > >=20
> > > On GNU/Linux, AIX, and Solaris, the processes keep busy and finish on=
e million
> > > lock/unlock cycles apiece in a few minutes.  On Cygwin, they hang wit=
hin a few
> > > seconds and under one hundred cycles apiece.  At that point, cygserve=
r is
> > > unresponsive to other clients; for example, "strace /bin/true", openi=
ng a new
> > > Cygwin terminal, "cat /proc/sysvipc/sem" and "cygserver -S" all hang.=
  In most
> > > tests, cygserver was not consuming CPU while unresponsive.
> >=20
> >=20
> > I pushed a patchset now, and uploaded new developer snapshots for
> > testing to https://cygwin.com/snapshots/
> >=20
> > I'm also going to create a 2.8.0-0.4 test release later today.
> >=20
> > Please give it a try, and please note that *all* patches affect
> > cygserver itself, so you have to test the new cygserver in the
> > first place.  The Cygwin DLL is not affected by the changes.
> >=20
> >=20
> > Thanks,
> > Corinna
> >=20
>=20
> Hi Corinna,
> just noted a small glitch.
>=20
> Attached a modification of Noah's test, it now accepts the number of work=
ers
> and semaphore are as before workers/4
>=20
> ./sema_parallel-2 32
>  worker ....
>  OK
>=20
> ./sema_parallel-2 64
> semget
> semget: Invalid argument
>=20
> If I restart the cygserver
>=20
> ./sema_parallel-2 64
>  worker ....
>  OK
>=20
> ./sema_parallel-2 128
> semget
> semget: Invalid argument
>=20
>=20
> It seems that the number of max available semaphores is frozen to first c=
all
> value.

That's normal and documented.  An existing semaphore set using the same
key has the number of semaphores defined in the first call, until you
remove the semaphore set with, for instance, ipcrm -s.  POSIX has this
to say:

   [EINVAL]
      The value of nsems is either less than or equal to 0 or greater
      than the system-imposed limit, or a semaphore identifier exists
      for the argument key, but the number of semaphores in the set
      associated with it is less than nsems and nsems is not equal to 0.

Linux doesn't care, but BSD does, and our XSI IPC code is 95% BSD.


Corinna

--IiVenqGWf+H9Y6IX
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJY1lTDAAoJEPU2Bp2uRE+gKIwQAIbLYT1N6RG4vIwxzpe2z05P
mrCg94CIwjBHVPSvh83hq+0fsuFzqzZ/tajszWsLHZkxGO/1x/YsRMV+OUHUQV8i
SIZJuD3oTqi/5uAim/nDqzpp/wo+Bz/v5q5ReMtkRWeNWhgjDHyYF/j31gDbhxia
GoUDOLicLCHgCyx65Ne5F9bGXsMdVOd26GejRgrHxmX8Fq/Qm3qlcYlwtsHQFl/u
wymSGGPasUE3aOrP6/5t6o+tKKTIQLSIQjqjWAlmC8k02b6GfHXUhvS/UDQoNftS
i9p/YnEyPeh1HYgwFZa8bugkljVgDL5U9/oNV8c5FR7y63YAd8pHacIBruhEXNcS
g8gFrHoJzA9zNEA4uu+HMvEseKa6P3vCg5745bQdOxP0aLhXwqVMfDuKKL04ZuAu
U2uqb459A+ojWbr6YNCrPQ43Cjk985+I05t2kqViatvOWj2d6dr0W+PdiZiqJuhd
5yn0zCqzRiVpSNL50nh8imfljhImZx9/o6khirBNUtddZKGRz5AM7+32Nvy7LOKj
/lP48k4FK1LwO6NdRJ7E6qMFfIf7L8crGr9eWKCO5AnsmavCIJ674v+16Lucbwtt
KQdhHagwdu45Mx1yFcjBrxYhZujV9j8dNxfcMi9Kv7Ax6Rk07/kHobPnHgCWWvIV
uILr8PSh8mvjDb2Gu6Fv
=WWvK
-----END PGP SIGNATURE-----

--IiVenqGWf+H9Y6IX--