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

[tingw.liu at gmail dot com]

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

--- Comment #6 from tingweiliu <tingw.liu at gmail dot com> 2012-08-21 06:06:58 UTC ---
(In reply to comment #5)
> 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

   Maybe you should check the code in attachment.
   I have set a future time, and semaphore value is initially zero and it's
never posted. So It should return with EINTR(errno=4).
   So anybody can tell me why it return with ETIMEOUT?




> 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.