I think it you review github.com/robaho/leveldb you’ll see that returning a copy works fine and has very little performance impact. If the caller then modifies it - that’s on them. Still, you could return an object like Value that is immutable with accessor methods.
You almost always need a copy anyway - since a caller often needs access to multiple values simultaneously. > On Oct 20, 2022, at 10:14 AM, Aaron Rubesh <aaronrube...@gmail.com> wrote: > > > In general, no. Each time you pass around a []byte you are actually passing > around a copy of a pointer to the slice. Modifications will affect the > underlying slice. > You can use arrays instead, which are always PBV. > Take care though, if you try to pass an array to a function accepting a slice > via arr[:] you will still end up modifying the underlying slice values. > > Examples: https://go.dev/play/p/qeUebAeXZAK > >> On Thursday, October 20, 2022 at 8:48:01 AM UTC-5 Ian Lance Taylor wrote: >> On Thu, Oct 20, 2022 at 5:46 AM Slawomir Pryczek <slawe...@gmail.com> wrote: >> > >> > Hi Guys, writing a quick K/V caching system and have a performance related >> > question. >> > >> > Will be operating on []byte, for the system to be thread safe we need to >> > create a copy of data before each SET so we're sure that the slice which >> > gets added to pool can't be modified. This shouldn't be problematic, but >> > there's a problem with GET. >> > >> > For the system to be thread-safe we need to isolate the returned slice >> > from the data pool so if we do, eg. x := Get("key_abc") we won't create >> > issues by later doing x[1]='a'. So we'll need to create a copy of whole >> > key for each GET. We will have very few SETs but millions of GETs. So is >> > it possible for the slice to be not-mutable like strings are or you can >> > suggest some other approach? >> >> What if you simply return a string? If the caller must not modify the >> returned data, a string is more or less the same as a []byte. >> >> Ian > > -- > 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 golang-nuts+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/golang-nuts/78f9482a-f795-48b6-a6d3-170c1cf4f8e3n%40googlegroups.com. -- 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 golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/526B9771-4143-40EE-9EAF-A5095A95AF21%40ix.netcom.com.
