173
86%
master: 98%

Ran 18 Jun 2024 09:49PM UTC

Files 8

Run time 1s

Badge

Embed ▾

Committed 18 Jun 2024 09:48PM UTC coverage: 97.222% (+0.05%) from 97.173%

Job # 173

Build Type

push

buildkite

Committed by

web-flow

Commit Message

Fixing data race (#29)

When reading and writing the same key simultaneously, there were two races that could occur while escalating the lock from a reader lock to a writer lock in the `get` method.

* The expiration check in `get` was reading `pqi.expiration`
* The returned value in `get` was reading `pqi.value`

Both of happened after the call to `lru.lock.RUnlock()`, which means that set could have modified the item that `pqi` was pointing to. We are now copying the underlying item (`*pqi`) to the stack and referencing that. This is a pessimistic way to approach this problem, but it is safe.

A test was added that highlighted these races when run with `-race`.

Thanks @coxley for pointing these out and giving me a test that showed the problem.

Run Details

665 of 684 relevant lines covered (97.22%)

502.86 hits per line

TriggerMail / lazylru / 173 / 173
86%
master: 98%

README BADGES
x

Markdown

Textile

RDoc

HTML

Rst

Source Files on job interface - 173

TriggerMail / lazylru / 173 / 173 86% master: 98%

README BADGES x

Markdown

Textile

RDoc

HTML

Rst

Source Files on job interface - 173

TriggerMail / lazylru / 173 / 173
86%
master: 98%

README BADGES
x