[Varnish] #1490: Is not release destroyed thread
Varnish
varnish-bugs at varnish-cache.org
Mon May 5 10:42:27 CEST 2014
#1490: Is not release destroyed thread
----------------------+-----------------------------------------------
Reporter: xcir | Owner: Martin Blix Grydeland <martin@…>
Type: defect | Status: closed
Priority: normal | Milestone:
Component: varnishd | Version: 4.0.0
Severity: normal | Resolution: fixed
Keywords: |
----------------------+-----------------------------------------------
Changes (by Martin Blix Grydeland <martin@…>):
* owner: => Martin Blix Grydeland <martin@…>
* status: new => closed
* resolution: => fixed
Comment:
In [5c12ec5f2568b43fc1f4cc68d76e9c9889462595]:
{{{
#!CommitTicketReference repository=""
revision="5c12ec5f2568b43fc1f4cc68d76e9c9889462595"
Remember to signal the thread to exit when decimating the flock
The pool herder didn't signal the thread when decimating the flock,
causing the thread to be leaked.
Spotted by: xcir
Fixes: #1490
Also close a couple of other races:
When pthread_cond_timedwait returns ETIMEDOUT, the predicate
(wrk->task.func == NULL) could still have changed while reacquiring
the mutex. If so, the signal would've been lost and the thread
leaked. Changed the idle wait loop in Pool_Work_Thread() to always
check the predicate before resuming the cond_wait.
The update of the predicate (wrk->task.func) from e.g. Pool_Task() is
done without holding the mutex. This opens a race on the predicate,
and the possibility of the worker going back on cond_wait loosing the
signal. Changed to update the predicate while holding the mutex.
}}}
--
Ticket URL: <https://www.varnish-cache.org/trac/ticket/1490#comment:2>
Varnish <https://varnish-cache.org/>
The Varnish HTTP Accelerator
More information about the varnish-bugs
mailing list