Re: gdb and multi-threaded (NPTL) programs

[Eric Desjardins <eric.desjardins@autodesk.com>]

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 à 21:24 +0100, Andreas Schwab a écrit :
> John Fodor <john_fodor@mac.com> writes:
> 
> > Hmmm... so people who use POSIX threads have to put every syscall into a 
> > loop, ignoring EINTR?
> 
> 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.
> 
> Andreas.