Re: [go-nuts] atomic package pointer operations with maps and channels
On Fri, Aug 11, 2017 at 6:22 PM, Ian Lance Taylor wrote: > On Fri, Aug 11, 2017 at 2:51 PM, Josh Humphries > 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.
Re: [go-nuts] atomic package pointer operations with maps and channels
On Fri, Aug 11, 2017 at 2:51 PM, Josh Humphries 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 > 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.
[go-nuts] atomic package pointer operations with maps and channels
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. 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. *Josh Humphries* jh...@bluegosling.com -- 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.
