sem_trywait never returns EAGAIN

sem_trywait never returns EAGAIN

[Patrick Frants]

Hi,

From the Linux man pages I concluded that calling sem_trywait on a semaphore with a zero count should result in an EAGAIN return value. I get a -1 all time 
time. Intiializing the count with 1 and calling sem_trywait two times results in 0 and -1 return codes. Initializing with 0, calling sem_trywait results in a -1 return 
code. Initializing with 0, calling sem_post, and sem_trywait twice results in 0 and -1 return codes for the sem_trywait calls.

Are my expectations wrong or is the behaviour of the library wrong?

Here is my sample code:

#include <pthread.h>
#include <semaphore.h>
#include <cassert>
#include <cstdio>

#pragma comment(lib, "pthreadvce")

int main(int argc, char** argv)
{
  sem_t s;
  assert(sem_init(&s, 0, 0) == 0);
  int result = sem_trywait(&s);
  if ( result == -1 )
  {
    perror("sem_wait"); // No error
  }
  else
  {
    printf("ok\n");
  }

  result = sem_post(&s);

  result = sem_trywait(&s);
  if ( result == -1 )
  {
    perror("sem_wait");
  }
  else
  {
    printf("ok\n");
  }

  return 0;
}
  
  

	
--
Patrick Frants
Senior Software Engineer
Quintiq
patrick@quintiq.com
www.quintiq.com

Re: sem_trywait never returns EAGAIN

[Ross Johnson]

It's fixed now.

This was a real bug in the library. A long time ago I must have
missed changing a pre-processor define in pthread.h, and this
caused the library to define and use it's own private errno.
This should have only been defined for WinCE.

On top of this, because of my limited understanding of MS compiler
flags, I had the wrong flag set when building the testsuite apps
(/MT instead of /MD). This cost me a day or two even after I'd
actually managed to fix the library, tests/semaphore1.c was
still producing errors.

So, together with trying to get the project in shape for a new
snapshot, this is why I haven't responded earlier.

Thanks for pointing out the error.
Ross

Patrick Frants wrote:
> 
> 2/26/2002 6:49:36 PM, "Bossom, John" <John.Bossom@Cognos.COM> wrote:
> 
> >Try checking the value of errno....
> >
> >Older UNIX methods would return -1 on failure and set errno to the actual
> >specific error.
> 
> I am working under windows with pthreads-win32 and checking errno gives 0.
> 
> Patrick
> 
> >
> >
> >-----Original Message-----
> >From: Patrick Frants [mailto:patrick@quintiq.com]
> >Sent: February 26, 2002 12:43 PM
> >To: pthreads-win32@sourceware.cygnus.com
> >Subject: sem_trywait never returns EAGAIN
> >
> >
> >Hi,
> >
> >From the Linux man pages I concluded that calling sem_trywait on a semaphore
> >with a zero count should result in an EAGAIN return value. I get a -1 all
> >time
> >time. Intiializing the count with 1 and calling sem_trywait two times
> >results in 0 and -1 return codes. Initializing with 0, calling sem_trywait
> >results in a -1 return
> >code. Initializing with 0, calling sem_post, and sem_trywait twice results
> >in 0 and -1 return codes for the sem_trywait calls.
> >
> >Are my expectations wrong or is the behaviour of the library wrong?
> >
> >Here is my sample code:
> >
> >#include <pthread.h>
> >#include <semaphore.h>
> >#include <cassert>
> >#include <cstdio>
> >
> >#pragma comment(lib, "pthreadvce")
> >
> >int main(int argc, char** argv)
> >{
> >  sem_t s;
> >  assert(sem_init(&s, 0, 0) == 0);
> >  int result = sem_trywait(&s);
> >  if ( result == -1 )
> >  {
> >    perror("sem_wait"); // No error
> >  }
> >  else
> >  {
> >    printf("ok\n");
> >  }
> >
> >  result = sem_post(&s);
> >
> >  result = sem_trywait(&s);
> >  if ( result == -1 )
> >  {
> >    perror("sem_wait");
> >  }
> >  else
> >  {
> >    printf("ok\n");
> >  }
> >
> >  return 0;
> >}
> >
> >
> >
> >
> >--
> >Patrick Frants
> >Senior Software Engineer
> >Quintiq
> >patrick@quintiq.com
> >www.quintiq.com
> >
> >
> >This message may contain privileged and/or confidential information.  If you
> >have received this e-mail in error or are not the intended recipient, you
> >may not use, copy, disseminate or distribute it; do not open any
> >attachments, delete it immediately from your system and notify the sender
> >promptly by e-mail that you have done so.  Thank you.
> >
> >
> --
> Patrick Frants
> Senior Software Engineer
> Quintiq
> patrick@quintiq.com
> www.quintiq.com

RE: sem_trywait never returns EAGAIN

[Bossom, John]

Try checking the value of errno....

Older UNIX methods would return -1 on failure and set errno to the actual
specific error.


-----Original Message-----
From: Patrick Frants [mailto:patrick@quintiq.com]
Sent: February 26, 2002 12:43 PM
To: pthreads-win32@sourceware.cygnus.com
Subject: sem_trywait never returns EAGAIN


Hi,

From the Linux man pages I concluded that calling sem_trywait on a semaphore
with a zero count should result in an EAGAIN return value. I get a -1 all
time 
time. Intiializing the count with 1 and calling sem_trywait two times
results in 0 and -1 return codes. Initializing with 0, calling sem_trywait
results in a -1 return 
code. Initializing with 0, calling sem_post, and sem_trywait twice results
in 0 and -1 return codes for the sem_trywait calls.

Are my expectations wrong or is the behaviour of the library wrong?

Here is my sample code:

#include <pthread.h>
#include <semaphore.h>
#include <cassert>
#include <cstdio>

#pragma comment(lib, "pthreadvce")

int main(int argc, char** argv)
{
  sem_t s;
  assert(sem_init(&s, 0, 0) == 0);
  int result = sem_trywait(&s);
  if ( result == -1 )
  {
    perror("sem_wait"); // No error
  }
  else
  {
    printf("ok\n");
  }

  result = sem_post(&s);

  result = sem_trywait(&s);
  if ( result == -1 )
  {
    perror("sem_wait");
  }
  else
  {
    printf("ok\n");
  }

  return 0;
}
  
  

	
--
Patrick Frants
Senior Software Engineer
Quintiq
patrick@quintiq.com
www.quintiq.com


This message may contain privileged and/or confidential information.  If you
have received this e-mail in error or are not the intended recipient, you
may not use, copy, disseminate or distribute it; do not open any
attachments, delete it immediately from your system and notify the sender
promptly by e-mail that you have done so.  Thank you.