From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8552 invoked by alias); 2 Mar 2002 06:08:20 -0000 Mailing-List: contact pthreads-win32-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: pthreads-win32-owner@sources.redhat.com Received: (qmail 8472 invoked from network); 2 Mar 2002 06:08:17 -0000 Received: from unknown (HELO real.ise.canberra.edu.au) (137.92.140.34) by sources.redhat.com with SMTP; 2 Mar 2002 06:08:17 -0000 Received: from ise.canberra.edu.au (IDENT:rpj@special.ise.canberra.edu.au [137.92.140.39]) by real.ise.canberra.edu.au (8.9.3/8.8.7) with ESMTP id RAA08000; Sat, 2 Mar 2002 17:07:44 +1100 Message-ID: <3C806C2E.798C7380@ise.canberra.edu.au> Date: Fri, 01 Mar 2002 22:08:00 -0000 From: Ross Johnson Reply-To: rpj@ise.canberra.edu.au Organization: University of Canberra, DMT, xISE X-Mailer: Mozilla 4.7 [en] (X11; U; Linux 2.2.12-20 i686) X-Accept-Language: en MIME-Version: 1.0 To: Patrick Frants CC: pthreads-win32@sourceware.cygnus.com Subject: Re: sem_trywait never returns EAGAIN References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SW-Source: 2002/txt/msg00031.txt.bz2 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" 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 > >#include > >#include > >#include > > > >#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