Mailing-List:	contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Subscribe:	<mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive:	<http://sources.redhat.com/ml/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-help AT cygwin DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender:	cygwin-owner AT cygwin DOT com
Delivered-To:	mailing list cygwin AT cygwin DOT com
Message-ID:	<026f01c1bea9$3963b230$0200a8c0@lifelesswks>
From:	"Robert Collins" <robert DOT collins AT itdomain DOT com DOT au>
To:	<cygwin AT cygwin DOT com>
References:	<005d01c1be6d$b9c6a2c0$6401a8c0 AT dopeslap2k> <20020226061305 DOT GA7735 AT redhat DOT com>
Subject:	Re: sem_trywait returns EAGAIN (rather than returning -1 and setting errno)
Date:	Tue, 26 Feb 2002 20:37:35 +1100
MIME-Version:	1.0
X-Priority:	3
X-MSMail-Priority:	Normal
X-Mailer:	Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE:	Produced By Microsoft MimeOLE V6.00.2600.0000
X-OriginalArrivalTime:	26 Feb 2002 09:36:34.0782 (UTC) FILETIME=[149F4FE0:01C1BEA9]

I haven't done much work on the sem* functions to date, other than
keeping the functional.

Patches, as always, gratefully accepted. Post daemon merge I can do a
review of the sem* functions.

The problem should _not_ be endemic in the pthreads code, as I rewrote
nearly all the pthread* functions from the P1003.1 draft spec.

Rob

===
----- Original Message -----
From: "Christopher Faylor" <cgf AT redhat DOT com>
To: <cygwin AT cygwin DOT com>
Sent: Tuesday, February 26, 2002 5:13 PM
Subject: Re: sem_trywait returns EAGAIN (rather than returning -1 and
setting errno)


> On Mon, Feb 25, 2002 at 09:31:41PM -0500, Andrew T. Schnable wrote:
> >I was doing some pthreads/semaphore work and I tracked down a problem
> >in my code to a bug in sem_trywait.  Posix sem_trywait is defined as
> >returning -1 and setting errno to EAGAIN if the semaphore would have
> >blocked.  The cygwin implementation returns EAGAIN an leaves errno
> >unchanged.
> >
> >Has anyone else encountered this problem and provided a fix?
>
> Hmm.  Unless I am missing something, it looks like this problem is
> prevalent in the pthreads code.  It makes me think that maybe the
> author meant to catch these kinds of things in the interface between
> the __pthread/pthread calls.
>
> Robert, can you explain what's going on here?
>
> cgf



--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

- Raw text -