acquire_sem_etc() really didn't like the combination of B_RELATIVE_TIMEOUT
and B_INFINITE_TIMEOUT -- it now does and won't start a timer anymore in this situation. Reported by Ingo. git-svn-id: file:///srv/svn/repos/haiku/trunk/current@10740 a95241bf-73f2-0310-859d-f6bbb57e9c96
This commit is contained in:
parent
849647ec72
commit
e3954f5a94
@ -456,6 +456,9 @@ acquire_sem_etc(sem_id id, int32 count, uint32 flags, bigtime_t timeout)
|
||||
goto err;
|
||||
}
|
||||
|
||||
if ((flags & (B_RELATIVE_TIMEOUT | B_ABSOLUTE_TIMEOUT)) == 0)
|
||||
timeout = B_INFINITE_TIMEOUT;
|
||||
|
||||
t->next_state = B_THREAD_WAITING;
|
||||
t->sem.flags = flags;
|
||||
t->sem.blocking = id;
|
||||
@ -465,7 +468,7 @@ acquire_sem_etc(sem_id id, int32 count, uint32 flags, bigtime_t timeout)
|
||||
t->sem.acquire_status = B_NO_ERROR;
|
||||
thread_enqueue(t, &sSems[slot].u.used.q);
|
||||
|
||||
if ((flags & (B_RELATIVE_TIMEOUT | B_ABSOLUTE_TIMEOUT)) != 0) {
|
||||
if (timeout != B_INFINITE_TIMEOUT) {
|
||||
TRACE(("sem_acquire_etc: setting timeout sem for %Ld usecs, semid %d, tid %d\n",
|
||||
timeout, id, t->id));
|
||||
|
||||
@ -505,7 +508,7 @@ acquire_sem_etc(sem_id id, int32 count, uint32 flags, bigtime_t timeout)
|
||||
scheduler_reschedule();
|
||||
RELEASE_THREAD_LOCK();
|
||||
|
||||
if ((flags & (B_TIMEOUT | B_ABSOLUTE_TIMEOUT)) != 0) {
|
||||
if (timeout != B_INFINITE_TIMEOUT) {
|
||||
if (t->sem.acquire_status != B_TIMED_OUT) {
|
||||
// cancel the timer event, the sem may have been deleted or interrupted
|
||||
// with the timer still active
|
||||
|
Loading…
x
Reference in New Issue
Block a user