Skip to content

tests: Fix a race in thread-pool-slow

Philip Withnall requested to merge pwithnall/glib:2810-thread-pool-slow into main

The race was already acknowledged in the code (via last_failed): the thread pool starts dequeuing jobs as soon as it’s created, so it’s dequeuing the sorted thread IDs while they’re still being enqueued and sorted. This can lead to them being dequeued out of the expected order if new thread IDs are enqueued out of order, which is possible because they’re randomly generated.

The test tried to handle this by allowing one out-of-order dequeue, but it looks like the race can race hard enough that multiple out-of-order dequeues are possible.

Fix that by only starting to dequeue the jobs from the thread pool once they’ve all been enqueued and put in a total order.

Signed-off-by: Philip Withnall philip@tecnocode.co.uk

Fixes: #2810 (closed)

Closes #2810 (closed)

Merge request reports