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>
>> 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>
>>> > 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.
You received this message because you are subscribed to the Google Groups
To unsubscribe from this group and stop receiving emails from it, send an email
For more options, visit https://groups.google.com/d/optout.