I'm building a toy key-value store. The key-value store is all in-memory
with a background goroutine that picks up the changes and persist them to
disk. When a call to `Put` is made, the affected value is flagged as Dirty
and eventually persisted by the background goroutine.
The API of my store takes <string, byte> pairs. My concern is that right
now, a client can give me a slice of byte, then modify it without me
picking up the change. It also modifies the value for all other clients (I
want my store to be concurrent-safe).
So the following test fails:
You can see it in context here :
The opposite is also true, I can currently modify the inner bytes of the
store by modifying the slice it returns me (see ).
I'm wondering which approach I should take:
1. Let the clients shoot themselves in the foot if they modify the value
2. Give the clients copies for every request?
3. Ask the clients to provide their own buffer on which I write. This
would give freedom to chose between speed/unsafe (1) or slow/safe (2), at
the cost of an uglier API.
4. ... something else?
: related question is that I'm getting lost as to how I should organize
my test code in an idiomatic way. I find that dskvs_test.go is getting
bloated. I'm also not quite sure of the approach I should take to properly
exercise the correct concurrent behavior of my library during tests; I have
one such test that is a naive attempt at it .
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to firstname.lastname@example.org.
For more options, visit https://groups.google.com/groups/opt_out.