On Tue, Oct 18, 2016 at 2:45 PM, Joshua Liebow-Feeser <he...@joshlf.com> wrote: > > On Tue, Oct 18, 2016 at 2:40 PM, Joshua Liebow-Feeser <he...@joshlf.com> > wrote: >> >> >> >> On Tue, Oct 18, 2016 at 2:16 PM, Ian Lance Taylor <i...@golang.org> wrote: >>> >>> On Tue, Oct 18, 2016 at 12:30 PM, Joshua Liebow-Feeser <he...@joshlf.com> >>> wrote: >>> > >>> > I'm playing around with implementing a wait-free channel in the runtime >>> > package, and as part of this, it'd be really nice to have double-word >>> > compare-and-swap (CAS). Barring that, however, for my purposes, it >>> > would >>> > actually be fine to have a one-word value that encodes both a pointer >>> > and >>> > some extra information using bit packing. The problem, though, is that >>> > if I >>> > store this value as, for example, a uintptr, the GC may not realize >>> > that >>> > it's a pointer. So my question is: are there any bits in a pointer >>> > which, >>> > when modified, won't mess with the GC? Note that since this is >>> > implemented >>> > in the runtime, I'm totally OK with relying on behavior specific to the >>> > current GC implementation. >>> >>> See runtime/lfstack*.go. >> >> Awesome, thanks! > > > Actually, quick follow-up. I noticed that the lfstack implementation > side-steps the GC issue by just not keeping pointers. That might work for me > if I just store runtime.g pointers, but that raises another question: can > the GC ever free g's, or are they just explicitly freed when a goroutine > quits? That is, is it safe for me to store a pointer/counter hybrid like in > lfstack - where that pointer is a *g - and assume that the GC won't collect > the g from out from under me?
For the specific case of a g, this is safe at the moment. The current Go runtime caches all g's and never releases them. See gfget and gfput in runtime/proc.go. 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.
