Incorrect cache duration due to a precision issue.

[Stumble]

Because internally the granulariry of expiration time is second, when the physical time is like xx::yy::zz.950 (950 ms passed for the second), and if we set a value with expiration of 1 second, the actual cache duration is only 50ms, instead of 1 second.

A test case to reproduce the issue:

diff --git a/cache_test.go b/cache_test.go
index 6082299..62e43b3 100644
--- a/cache_test.go
+++ b/cache_test.go
@@ -43,6 +43,24 @@ func (mock *mockTimer) NowCallsCount() int {
        return int(atomic.LoadUint32(&mock.nowCallsCnt))
 }
 
+func TestFlakyDuration(t *testing.T) {
+       for {
+               cache := NewCache(1024)
+               err := cache.Set([]byte("key"), []byte("val"), 1)
+               if err != nil {
+                       panic(err)
+               }
+               time.Sleep(200 * time.Millisecond)
+               v, err := cache.Get([]byte("key"))
+               if err != nil {
+                       panic(err)  // <- will failed here when the time is right:)
+               }
+               if string(v) != "val" {
+                       t.Error("test failed")
+               }
+       }
+}
+
:

Shall we consider to use milliseconds internally?

[coocood]

Uint32 is not large enough to include milliseconds.

[Stumble]

Understood. Is it possible to change it to uint64?

[coocood]

Understood. Is it possible to change it to uint64?

It is possible but maybe not worth to do so.
The memory usage would increase 8 bytes per entry.

[Stumble]

Make sense. Sounds like a reasonable trade-off. Should it be documented somewhere?

Btw why is it 8 bytes more instead of 4 bytes more?

[coocood]

Each entry stores two Uint32 values, accessTime and expireAt.

Yes, it could be documented, would you like to send a PR for it?

[Stumble]

sure thing: #119

[coocood]

Thank you for the help!