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.

Reply via email to