On Fri, Aug 11, 2017 at 6:22 PM, Ian Lance Taylor <i...@golang.org> wrote:
> On Fri, Aug 11, 2017 at 2:51 PM, Josh Humphries <jh...@bluegosling.com>
> > It is possible to extract a map's actual value/address if it is stored in
> > the heap -- by using something like this:
> > atomic.LoadPointer((*unsafe.Pointer)(unsafe.Pointer(&m)))
> > However, it does not appear to possible to go the other direction, even
> > using unsafe. Specifically, to take an unsafe.Pointer and somehow store
> > in a variable whose type is a map.
> var m map[int]bool
> *(*unsafe.Pointer)(unsafe.Pointer(&m)) = myMapPointer
Thanks! I had thought about something like that and dismissed it because I
thought it would spill m to the heap instead of stack allocating it. (But I
guess the compiler is probably smart enough to see that &m never escapes,
so it could still be stack allocated?)
Even if it does a heap allocation, it's still strictly better than the
solution I mentioned below of using an intermediate struct pointer. So not
sure why I didn't thank of that. Thanks again.
> > 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
> > atomic.LoadX).
> > 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
> > 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
> > 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
> > the doc for reflect.Value.Pointer() implies that they are (same for
> > channels).
> > Is there a particular reason that casting a map (or chan) to
> > 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.