[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