From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gdb-return-24648-listarch-gdb=sources.redhat.com@sourceware.org>
Received: (qmail 10347 invoked by alias); 24 Mar 2006 20:27:49 -0000
Received: (qmail 10339 invoked by uid 22791); 24 Mar 2006 20:27:49 -0000
X-Spam-Check-By: sourceware.org
Received: from Unknown (HELO smtp.discreet.com) (207.35.253.199)     by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 24 Mar 2006 20:27:47 +0000
Received: from cuba.discreet.qc.ca (cuba.discreet.qc.ca [172.16.50.110]) 	by cuba.discreet.qc.casmtp.discreet.com (8.12.9/8.12.9) with ESMTP id k2OKRh8E012703; 	Fri, 24 Mar 2006 15:27:43 -0500
Received: from saskatoon.rd.discreet.qc.ca (saskatoon.rd.discreet.qc.ca [172.16.129.95]) 	by cuba.discreet.qc.ca (SGI-8.12.5/8.12.5) with ESMTP id k2OKRbim1973485; 	Fri, 24 Mar 2006 15:27:37 -0500 (EST)
Received: from saskatoon.rd.discreet.qc.ca (localhost [127.0.0.1]) 	by saskatoon.rd.discreet.qc.ca (8.13.1/8.13.1) with ESMTP id k2OKRbed015982; 	Fri, 24 Mar 2006 15:27:37 -0500
Received: (from desjare@localhost) 	by saskatoon.rd.discreet.qc.ca (8.13.1/8.13.1/Submit) id k2OKRanu015981; 	Fri, 24 Mar 2006 15:27:36 -0500
Subject: Re: gdb and multi-threaded (NPTL) programs
From: Eric Desjardins <eric.desjardins@autodesk.com>
To: Andreas Schwab <schwab@suse.de>
Cc: John Fodor <john_fodor@mac.com>, gdb@sourceware.org
In-Reply-To: <je4q1n4mmp.fsf@sykes.suse.de>
References: <44244F1F.6030108@mac.com>  <je4q1n4mmp.fsf@sykes.suse.de>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Date: Fri, 24 Mar 2006 20:45:00 -0000
Message-Id: <1143232056.6264.29.camel@saskatoon.rd.discreet.qc.ca>
Mime-Version: 1.0
Mailing-List: contact gdb-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Subscribe: <mailto:gdb-subscribe@sourceware.org>
List-Archive: <http://sourceware.org/ml/gdb/>
List-Post: <mailto:gdb@sourceware.org>
List-Help: <mailto:gdb-help@sourceware.org>, <http://sourceware.org/ml/#faqs>
Sender: gdb-owner@sourceware.org
X-SW-Source: 2006-03/txt/msg00175.txt.bz2

Hi,

Well I was suprised at first when I discover that. On my RHEL 4.0
machine, the man page is not very EINTR aware. Maybe it is a man page
bug?

Eric

RETURN VALUE
       The sem_wait and sem_getvalue functions always return 0.  All
other semaphore functions return 0 on success and -1
       on error, in addition to writing an error code in errno.

ERRORS
       The sem_init function sets errno to the following codes on error:

              EINVAL value exceeds the maximal counter value
SEM_VALUE_MAX

              ENOSYS pshared is not zero

       The sem_trywait function sets errno to the following error code
on error:

              EAGAIN the semaphore count is currently 0

       The sem_post function sets errno to the following error code on
error:

              ERANGE after  incrementation,  the  semaphore value would
exceed SEM_VALUE_MAX (the semaphore count is left
                     unchanged in this case)

       The sem_destroy function sets errno to the following error code
on error:

              EBUSY  some threads are currently blocked waiting on the
semaphore.

AUTHOR
       Xavier Leroy <Xavier.Leroy@inria.fr>


Le vendredi 24 mars 2006 =C3=A0 21:24 +0100, Andreas Schwab a =C3=A9crit :
> John Fodor <john_fodor@mac.com> writes:
>=20
> > Hmmm... so people who use POSIX threads have to put every syscall into =
a=20
> > loop, ignoring EINTR?
>=20
> Every library call that is allowed to return with EINTR must be handled
> appropriately.  sem_wait is specified as being able to return with EINTR.
> If your program can't handle that it has a bug.
>=20
> Andreas.