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> > wrote: > > > > 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 > 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 > > 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 > 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 > > channels). > > > > > > 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. > > 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. For more options, visit https://groups.google.com/d/optout.
