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
>> > 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
>> > when modified, won't mess with the GC? Note that since this is
>> > 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?
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.