On Tue, Nov 16, 2021 at 1:25 PM Stephen Illingworth < stephen.illingwo...@gmail.com> wrote:
> I've found that the way around this is to create a new instance of > atomic.Value whenever I have reason to believe that the type to be stored > has changed. > That seems to be counter to the idea behind `atomic.Value`. Creating and setting the new `atomic.Value` requires synchronization. If you need synchronization anyway, it seems better to just use that synchronization to serialize *all* read/writes. > In my program this can happen because I am storing an interface in the > atomic.Value and the implementation of the interface may change. > I think the best way to address that might be to store a pointer to an interface-type. That's similar to how you want to proceed if you want to get an interface-typed reflect.Value, so you do `reflect.ValueOf(&r).Elem()` (if `r` is an `io.Reader`, for example). > Choosing the moment to create the new atomic.Value however can be tricky > so I am now trying the following method: > > 1) Check the type of the existing stored value and the type of the new > value > 2) If they are the same then atomic.Value.Store() can be used > 3) If they are not the same, then create a new instance of atomic.Value > and store new value in that > 4) Give the new atomic.Value the name of the old atomic.Value > 4 is, FTR, the part where this breaks. This assignment is not atomic. > This method means I no longer have to worry about when I create a new > instance of atomic.Value - the new instance is created when the type check > fails. > > Example code. > > https://play.golang.org/p/1gmI5eMdOcl > > Now, this obviously requires knowledge of how interface{} is represented > internally, which isn't great, but in principle is this a correctly working > solution? (It seems to be to me but that doesn't really mean anything) > > Does returning an atomic.Value from a function count as "copying" after > first use? > > Is this going to bite me in the future? > > -- > 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/8893475a-ec61-4f78-9dc0-b80dda9e675an%40googlegroups.com > <https://groups.google.com/d/msgid/golang-nuts/8893475a-ec61-4f78-9dc0-b80dda9e675an%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- 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/CAEkBMfEq2J2o8OgMYWD5Je27g3-qtPd6Dz%2BzK-nHAaYRpuaV%2Bw%40mail.gmail.com.
