RE: sem_trywait returns EAGAIN (rather than returning -1 and setting errno)

RE: sem_trywait returns EAGAIN (rather than returning -1 and setting errno)

[Robert Collins]

FWIW, I've patched sem_trywait and sem_wait. I haven't looked for further cases of misbehaviour though.

Rob

> -----Original Message-----
> From: Christopher Faylor [mailto:cgf@redhat.com] 

> As Robert indicated, in the vast majority of those cases, 
> this was, in fact, the right thing to do.
> 
> It's apparently not the right thing to do in the case of 
> sem_trywait, so a patch will be required:  
> http://cygwin.com/contrib.html .


--
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/

Re: sem_trywait returns EAGAIN (rather than returning -1 and setting errno)

[Andrew T. Schnable]

I think all the sem_* functions are broken similarly.  I have the threads.cc file modified 
and was going to try and submit patches, but I am having some issues getting
the regression tests working (even before I put my changes in...)  A soon as
I get these issues resolved and verify my fixes, I can try and submit 
a patch for everything (like all good cygwin users should!)  (Unless of course you
beat me to it - and at this rate - you will!)

Thanks for helping me out with this.

Andy
schnable@enteract.com


----- Original Message ----- 
From: "Robert Collins" <robert.collins@itdomain.com.au>
To: <cygwin@cygwin.com>
Cc: "Andrew T. Schnable" <schnable@enteract.com>
Sent: Thursday, February 28, 2002 8:55 AM
Subject: RE: sem_trywait returns EAGAIN (rather than returning -1 and setting errno)


FWIW, I've patched sem_trywait and sem_wait. I haven't looked for further cases of misbehaviour though.

Rob

> -----Original Message-----
> From: Christopher Faylor [mailto:cgf@redhat.com] 

> As Robert indicated, in the vast majority of those cases, 
> this was, in fact, the right thing to do.
> 
> It's apparently not the right thing to do in the case of 
> sem_trywait, so a patch will be required:  
> http://cygwin.com/contrib.html .


--
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/




--
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/

RE: sem_trywait returns EAGAIN (rather than returning -1 and setting errno)

[Gerald S. Williams]

Andrew T. Schnable [mailto:schnable@enteract.com] wrote:
> I think all the sem_* functions are broken similarly. [ ... ]

I just came across this myself while working on enabling
Cygwin Python threads. You may find the following function
helpful:

static int
fix_status(int status)
{
	return (status == -1) ? errno : status;
}

I defined it as a routine rather than a macro so that you
can use it on a single line without mistakenly calling
the function twice. E.g.,
	status = fix_status(sem_wait(thelock));

This should work for any function that returns 0 for success
and -1 for failure (putting the error code in errno), since
0 is never a legal errno code. You may find it useful if you
are using pthreads and semaphore code at the same time and
want the return codes to work the same.

-Jerry

-O Gerald S. Williams, 22Y-103GA : mailto:gsw@agere.com O-
-O AGERE SYSTEMS, 555 UNION BLVD : office:610-712-8661  O-
-O ALLENTOWN, PA, USA 18109-3286 : mobile:908-672-7592  O-


--
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/

RE: sem_trywait returns EAGAIN (rather than returning -1 and setting errno)

[Robert Collins]

> -----Original Message-----
> From: Andrew T. Schnable [mailto:schnable@enteract.com] 
> returning -1 and setting errno)
> 
> 
> I think all the sem_* functions are broken similarly.  I have 
> the threads.cc file modified 
> and was going to try and submit patches, but I am having some 
> issues getting the regression tests working (even before I 
> put my changes in...)  A soon as I get these issues resolved 
> and verify my fixes, I can try and submit 
> a patch for everything (like all good cygwin users should!)  
> (Unless of course you beat me to it - and at this rate - you will!)
> 
> Thanks for helping me out with this.

No probs. Just drop the patch in , properly changelogged and formatted.
I'll eyeball it for regressions (The pthreads code is (mostly) trivial,
so I comfortable with this.). I/We'll need to write some new regression
tests though. 

Rob

--
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/

RE: sem_trywait returns EAGAIN (rather than returning -1 and setting errno)

[Robert Collins]

> -----Original Message-----
> From: Christopher Faylor [mailto:cgf@redhat.com] 

> On Tue, Feb 26, 2002 at 08:37:35PM +1100, Robert Collins wrote:
> >The problem should _not_ be endemic in the pthreads code, as 
> I rewrote 
> >nearly all the pthread* functions from the P1003.1 draft spec.
> 
> % grep 'return E' thread.cc

*Sigh*. That just shows that that is what the code is meant to do.
If you check the spec, you'll see that most of the pthread functions are meant to return the error number.

i.e. picking a function at random - pthread_mutex_lock 
"
RETURN VALUE
If successful, the pthread_mutex_lock( ) and pthread_mutex_unlock( ) functions shall return zero;
otherwise, an error number shall be returned to indicate the error.
"


Rob

--
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/

Re: sem_trywait returns EAGAIN (rather than returning -1 and setting errno)

[Christopher Faylor]

On Wed, Feb 27, 2002 at 09:08:54AM +1100, Robert Collins wrote:
>
>
>> -----Original Message-----
>> From: Christopher Faylor [mailto:cgf@redhat.com] 
>
>> On Tue, Feb 26, 2002 at 08:37:35PM +1100, Robert Collins wrote:
>> >The problem should _not_ be endemic in the pthreads code, as 
>> I rewrote 
>> >nearly all the pthread* functions from the P1003.1 draft spec.
>> 
>> % grep 'return E' thread.cc
>
>*Sigh*. That just shows that that is what the code is meant to do.

In other words, RTFM, cgf.  When you think about it, it would make zero
sense for functions which dealt with threads to set errno.

Sorry about that.  I REALLY should have known better on multiple counts.

(hangs head in shame)
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/

Re: sem_trywait returns EAGAIN (rather than returning -1 and setting errno)

[Andrew T. Schnable]

You have a point regarding errno, but unfortunately, this is how the
standard
is written. If it's intentional that cygwin deviate from posix 1.b, I'm fine
with that - I can code accordingly.  FYI - I went to the

    The Open Group Base Specifications Issue 6
    technically identical to IEEE Std 1003.1-2001
    Copyright © 2001 The IEEE and The Open Group

(because this was easier to find on-line and it should be close enough,)
and snipped this fragment from the sem_trywait man page...

http://www.opengroup.org/onlinepubs/007904975/functions/sem_trywait.html

    RETURN VALUE
    The sem_trywait() and sem_wait() functions shall return zero if the
calling
    process  successfully performed the semaphore lock operation on the
    semaphore designated by  sem. If the call was unsuccessful, the state of
    the semaphore shall be unchanged, and the function shall return a value
    of -1 and set errno to indicate the error.

I reading the wrong version of the standard?  This is how sem_trywait
worked on QNX; Where can I find the cygwin manual pages for the
sem_functions?

Andy

PS. Previous systems I have worked on put errno in thread specific data
making
the code using errno thread safe; the POSIX standard now specifies that
errno can be
something other than an "extern int" - it simply has to be a lvalue - you
can
make errno be a macro that maps to the thread specific data location.

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


> On Wed, Feb 27, 2002 at 09:08:54AM +1100, Robert Collins wrote:
> >
> >
> >> -----Original Message-----
> >> From: Christopher Faylor [mailto:cgf@redhat.com]
> >
> >> On Tue, Feb 26, 2002 at 08:37:35PM +1100, Robert Collins wrote:
> >> >The problem should _not_ be endemic in the pthreads code, as
> >> I rewrote
> >> >nearly all the pthread* functions from the P1003.1 draft spec.
> >>
> >> % grep 'return E' thread.cc
> >
> >*Sigh*. That just shows that that is what the code is meant to do.
>
> In other words, RTFM, cgf.  When you think about it, it would make zero
> sense for functions which dealt with threads to set errno.
>
> Sorry about that.  I REALLY should have known better on multiple counts.
>
> (hangs head in shame)
> 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/
>
>


--
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/

Re: sem_trywait returns EAGAIN (rather than returning -1 and setting errno)

[Christopher Faylor]

On Tue, Feb 26, 2002 at 07:14:35PM -0500, Andrew T. Schnable wrote:
>You have a point regarding errno, but unfortunately, this is how the
>standard
>is written. If it's intentional that cygwin deviate from posix 1.b, I'm fine
>with that - I can code accordingly.  FYI - I went to the
>
>    The Open Group Base Specifications Issue 6
>    technically identical to IEEE Std 1003.1-2001
>    Copyright ? 2001 The IEEE and The Open Group
>
>(because this was easier to find on-line and it should be close enough,)
>and snipped this fragment from the sem_trywait man page...

I wasn't referring to the specific case that you reported.  I was just
referring to my grep which found many cases where an errno value was
being returned.

As Robert indicated, in the vast majority of those cases, this was, in
fact, the right thing to do.

It's apparently not the right thing to do in the case of sem_trywait, so
a patch will be required:  http://cygwin.com/contrib.html .

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/

Re: sem_trywait returns EAGAIN (rather than returning -1 and setting errno)

[Andrew T. Schnable]

cool - I misunderstood.  I will try and work up a patch...

Andy

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


> On Tue, Feb 26, 2002 at 07:14:35PM -0500, Andrew T. Schnable wrote:
> >You have a point regarding errno, but unfortunately, this is how the
> >standard
> >is written. If it's intentional that cygwin deviate from posix 1.b, I'm
fine
> >with that - I can code accordingly.  FYI - I went to the
> >
> >    The Open Group Base Specifications Issue 6
> >    technically identical to IEEE Std 1003.1-2001
> >    Copyright ? 2001 The IEEE and The Open Group
> >
> >(because this was easier to find on-line and it should be close enough,)
> >and snipped this fragment from the sem_trywait man page...
>
> I wasn't referring to the specific case that you reported.  I was just
> referring to my grep which found many cases where an errno value was
> being returned.
>
> As Robert indicated, in the vast majority of those cases, this was, in
> fact, the right thing to do.
>
> It's apparently not the right thing to do in the case of sem_trywait, so
> a patch will be required:  http://cygwin.com/contrib.html .
>
> 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/
>
>


--
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/

sem_trywait returns EAGAIN (rather than returning -1 and setting errno)

[Andrew T. Schnable]

Greetings,

    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?

Andy
schnable@enteract.com

PS. The problem seems to be in thread.cc (semaphore::TryWait) -  I don't see
much
stderr setting anywhere in this file - is this verboten - or just
overlooked?


int
semaphore::TryWait ()
{
  /*FIXME: signals should be able to interrupt semaphores...
   *We probably need WaitForMultipleObjects here.
   */
  if (WaitForSingleObject (win32_obj_id, 0) == WAIT_TIMEOUT)
    return EAGAIN;
  currentvalue--;
  return 0;
}


--
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/

Re: sem_trywait returns EAGAIN (rather than returning -1 and setting errno)

[Christopher Faylor]

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

>Andy
>schnable@enteract.com
>
>PS. The problem seems to be in thread.cc (semaphore::TryWait) -  I don't see
>much
>stderr setting anywhere in this file - is this verboten - or just
>overlooked?
>
>
>int
>semaphore::TryWait ()
>{
>  /*FIXME: signals should be able to interrupt semaphores...
>   *We probably need WaitForMultipleObjects here.
>   */
>  if (WaitForSingleObject (win32_obj_id, 0) == WAIT_TIMEOUT)
>    return EAGAIN;
>  currentvalue--;
>  return 0;
>}

--
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/

Re: sem_trywait returns EAGAIN (rather than returning -1 and setting errno)

[Robert Collins]

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@redhat.com>
To: <cygwin@cygwin.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/

Re: sem_trywait returns EAGAIN (rather than returning -1 and setting errno)

[Christopher Faylor]

On Tue, Feb 26, 2002 at 08:37:35PM +1100, Robert Collins wrote:
>The problem should _not_ be endemic in the pthreads code, as I rewrote
>nearly all the pthread* functions from the P1003.1 draft spec.

% grep 'return E' thread.cc
      return ETIMEDOUT;
    return EAGAIN;
    return EFAULT;
    return EINVAL;
      return EAGAIN;
    return ESRCH;
  return ESRCH;
  we return ESRCH until all the required functions call testcancel ();
    return EINVAL;
    return EINVAL;
	return ENOMEM;
	  return ENOMEM;
	  return ENOMEM;
    return EINVAL;
      return EAGAIN;
    return EINVAL;
    return EINVAL;
    return EINVAL;
    return EINVAL;
    return EINVAL;
    return EINVAL;
    return EINVAL;
    return EINVAL;
    return ENOTSUP;
    return EINVAL;
    return ENOTSUP;
    return EINVAL;
    return ENOTSUP;
    return EINVAL;
    return EINVAL;
    return ENOTSUP;
    return EINVAL;
    return EINVAL;
    return EINVAL;
    return ESRCH;
      return EINVAL;
    return ESRCH;
      return EINVAL;
    return ESRCH;
    return ESRCH;
    return ESRCH;
    return EINVAL;
    return EBUSY;
      return EAGAIN;
    return EINVAL;
    return EINVAL;
    return ESRCH;
    return ENOTSUP;
    return EINVAL;
    return EINVAL;
    return EINVAL;
    return EBUSY;
    return EINVAL;
    return EBUSY;
      return EAGAIN;
    return EINVAL;
    return EINVAL;
    return EINVAL;
    return EINVAL;
	return EINVAL;
    return EINVAL;
    return ETIMEDOUT;
      return EAGAIN;
    return EINVAL;
    return EINVAL;
    return EINVAL;
    return EINVAL;
    return EINVAL;
    return EINVAL;
    return EINVAL;
    return EBUSY;
      return EAGAIN;
    return EINVAL;
  return ENOSYS;
      return EINVAL;
    return EINVAL;
    return EBUSY;
    return EINVAL;
    return EINVAL;
    return EBUSY;
    return EINVAL;
  return ENOSYS;
    return EINVAL;
  return ENOSYS;
    return EINVAL;
 *PTHREAD_MUTEX_DEFAULT to PTHREAD_MUTEX_RECURSIVE and return EINVAL for other types.
    return EINVAL;
    return EBUSY;
      return ENOMEM;
    return EINVAL;
    return EINVAL;
  return ENOSYS;
    return EINVAL;
  return ENOSYS;
    return EINVAL;
  return ENOSYS;
    return EINVAL;
    return EINVAL;
    return EINVAL;
    return EINVAL;
    return EBUSY;
    return EINVAL;
      return EAGAIN;
    return EINVAL;
    return EINVAL;
    return EINVAL;
    return EINVAL;

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/