On Fri, Aug 11, 2017 at 2:51 PM, Josh Humphries <jh...@bluegosling.com> wrote:
> It is possible to extract a map's actual value/address if it is stored in
> the heap -- by using something like this:
> However, it does not appear to possible to go the other direction, even if
> using unsafe. Specifically, to take an unsafe.Pointer and somehow store it
> in a variable whose type is a map.
var m map[int]bool
*(*unsafe.Pointer)(unsafe.Pointer(&m)) = myMapPointer
> My use case wants to be able to lazily compute the map, but then use
> atomic.StoreX to safely set the field value for a struct that could be
> accessed from multiple goroutines. (Readers would, of course, use
> But it doesn't look like this is possible. And I cannot use atomic.Value
> because I need the structs to be copy-able. I can't copy a struct with
> atomic.Value nested in it because it embeds the special noCopy type. (I know
> the compiler will allow the copy, but I want to do this in a library and
> don't want users of the library to see errors reported by "go vet" due to
> copying this type.)
> My current solution is to add another pointer indirection -- so I stick the
> map in a struct, and then I can use atomic.LoadPointer and
> atomic.StorePointer to atomically change a pointer to that struct.
> But that seemed a little silly since. Though the language spec does not
> describe maps as pointers, blog posts describe them as reference types and
> the doc for reflect.Value.Pointer() implies that they are (same for
> Is there a particular reason that casting a map (or chan) to unsafe.Pointer,
> and vice versa, is disallowed? We're already using the unsafe package, so I
> can't think of a clear reason to prevent this.
>From a language perspective, there is no reason to lock map and
channel values into always being pointer values.
You received this message because you are subscribed to the Google Groups
To unsubscribe from this group and stop receiving emails from it, send an email
For more options, visit https://groups.google.com/d/optout.