> 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. >
Yes. I can see that now. The creation of the new atomic.Value could happen any time. I've been leaning on the race detector and this technique has never triggered anything but that's probably just good fortune. > 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). > How about just a 'container' type for the interface. https://play.golang.org/p/WSXVjVHj1Ya For what I need, that does the job nicely. The type being stored in the atomic.Value isn't changing so it satisfies the atomic.Value constraints but I have the flexibility of the contained type being able to change. Any pitfalls with this? -- 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/3f1d0c92-4ded-4096-95d9-069a9b5d78cen%40googlegroups.com.
