This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug nptl/14484] sem_timedwait always return -1 with errno 110 (ETIMEDOUT).
- From: "bugdal at aerifal dot cx" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sources dot redhat dot com
- Date: Mon, 20 Aug 2012 01:41:02 +0000
- Subject: [Bug nptl/14484] sem_timedwait always return -1 with errno 110 (ETIMEDOUT).
- Auto-submitted: auto-generated
- References: <bug-14484-131@http.sourceware.org/bugzilla/>
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.