This is the mail archive of the glibc-bugs@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug nptl/14484] sem_timedwait always return -1 with errno 110 (ETIMEDOUT).


http://sourceware.org/bugzilla/show_bug.cgi?id=14484

--- Comment #5 from Rich Felker <bugdal at aerifal dot cx> 2012-08-20 01:41:02 UTC ---
As far as I can tell this report is invalid and is just a case of the reporter
not understanding the interface. In particular, assuming the semaphore value is
initially zero and it's never posted:

1. sem_timedwait should fail with ETIMEDOUT if the given time has already
passed when it's called.

2. sem_timedwait should sleep until the given time, then fail with ETIMEDOUT,
if the given time is in the future.

3. Signals that arrive during the wait should have no effect on sem_timedwait
unless the handler was installed without the SA_RESTART option.

Note that point 3 is not honored on most (all?) Linux versions; syscalls with
timeouts get interrupted with EINTR even if the signal handler was installed
with SA_RESTART. This is a bug in Linux, not glibc, and is impossible to fix at
the libc level.

If you still believe there's a glibc bug here, please explain what you expect
the behavior to be in terms of the specification of the sem_timedwait function.
As I've said, I can't see any bug...

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]