TestRingLossy fails with drain error about ristretto

[karlmcguire]

Here's what I'm thinking, rather than an exact, single threaded test:

func TestRingLossy(t *testing.T) {
	drainCount := 0
	buffer := newRingBuffer(ringLossy, &ringConfig{
		Consumer: &TestConsumer{
			push: func(items []uint64) {
				drainCount++
			},
		},
		Capacity: 4,
	})
	for i := 0; i < 100; i++ {
		buffer.Push(uint64(i))
	}
	// ideally we'd be able to check for a certain "drop percentage" here, but
	// that may vary per platform and testing configuration. for example: if
	// drainCount == 20 then we have 100% accuracy, but it's most likely around
	// 13-20 due to dropping and unfilled rings.
	if drainCount == 0 {
		t.Fatal("drain error")
	}
}

[jarifibrahim]

@karlmcguire I thought of doing something along similar lines. Do you mind sending a PR? I ran your snippet and I didn't see any failures after running the test for ~10m.

[jarifibrahim]

ristretto/ring.go

Lines 127 to 132 in ae326c3

	func pushLossy(b *ringBuffer, item uint64) {
	// reuse or create a new stripe
	stripe := b.pool.Get().(*ringStripe)
	stripe.Push(item)
	b.pool.Put(stripe)
	}

uses sync.Pool(..) and sync.Pool is not guaranteed to return the objects that were inserted into it.
When the test is run with -race flag, there are multiple ring strips created and hence none of them reach capacity.

[karlmcguire]

I see. We need another way to make sure ringLossy is draining properly even with the -race flag. The behavior we're seeing now is the correct behavior, it's just hard to test.