On Wed, Apr 22, 2020 at 7:08 AM T L <[email protected]> wrote: > > I understand that, by the case 6 in the unsafe package docs, > the second program should be safe with or without the runtime.KeepAlive call. > I just wonder how Go runtime achieves this goal. > I have an impression that pointer assignments in Go by gc is atomically, > but is this also true for uintptr value assignments?
Using the meaning of "atomic" from my previous message, then, yes, both pointer assignments and uintptr assignments are done in a way that can not be interrupted. That more or less happens automatically, as it's a single machine instruction either way. And in fact it's the same machine instruction, since pointers and uintptr are the same size and use the same registers. Ian > On Wednesday, April 22, 2020 at 7:33:22 AM UTC-4, T L wrote: >> >> >> >> On Tuesday, April 21, 2020 at 8:13:17 PM UTC-4, Ian Lance Taylor wrote: >>> >>> On Tue, Apr 21, 2020 at 8:17 AM T L <[email protected]> wrote: >>> > >>> > And is the runtime.KeepAlive call in the following program essential to >>> > keep the correctness? >>> > >>> > package main >>> > >>> > import ( >>> > "fmt" >>> > "unsafe" >>> > "reflect" >>> > "runtime" >>> > ) >>> > >>> > func main() { >>> > a := [6]byte{'G', 'o', 'o', 'g', 'l', 'e'} >>> > bs := []byte("Golang") >>> > hdr := (*reflect.SliceHeader)(unsafe.Pointer(&bs)) >>> > hdr.Data = uintptr(unsafe.Pointer(&a)) >>> > >>> > runtime.KeepAlive(&a) // Is this line essential here? >>> > >>> > hdr.Len = 2 >>> > hdr.Cap = len(a) >>> > fmt.Printf("%s\n", bs) // Go >>> > bs = bs[:cap(bs)] >>> > fmt.Printf("%s\n", bs) // Google >>> > } >>> >>> I do not think the runtime.KeepAlive is required. Setting the Data >>> field using a *SliceHeader should keep the value alive. >>> >>> Ian >> >> >> >> Many thanks for the answers. >> >> I have another question, which doesn't matter with or without the >> runtime.KeepAlive call. >> We know that assignment in Go is not atomic. >> Is it possible that when the assignment "hdr.Data = >> uintptr(unsafe.Pointer(&a))" is half done, >> the stack is resized, so the address of a might be changed (assume a is >> allocated on stack), >> the hdr.Data will be assigned the old invalid value? >> > -- > 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 [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/golang-nuts/2b9b1bec-4176-421f-8820-a6ff2bf2ead2%40googlegroups.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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAOyqgcVd6cjuu0Sv9SpgqcnZ8cEG%2B6kXpbLQz70VL8Jr%2B5VeBg%40mail.gmail.com.
