On Wed, Mar 22, 2017 at 3:59 AM, T L <tapir....@gmail.com> wrote:
>
> On Wednesday, March 22, 2017 at 6:40:53 PM UTC+8, Jesse McNelis wrote:
>>
>> On Wed, Mar 22, 2017 at 8:51 PM, T L <tapi...@gmail.com> wrote:
>> >
>> > More accurately, I think it should be: from the POV of a programmer,
>> > it's
>> > globals, and things reachable from each goroutine.
>> >
>>
>> The only way to reach a value is through a variable in scope and the
>> only variables in scope are global or on the stack.
>>
>> 'heap pointers of local allocated memory blocks' are stored where ever
>> you put them, but you can only put them in places you can find by
>> using global or local stack variables.
>
>
> So for this simple program:
>
> func main() {
> var a int
> go func() { // new goroutine
> a++
> }()
>
> // ...
> }
>
> a will be allocated on heap.
> a is referenced by both stack of main and the new goroutine?
> how is it referenced, the pointer of a's memory block is stored in both
> stacks?
The pointer to a's memory is accessible from the stack of both
goroutines. Otherwise the goroutines could not possibly refer to a.
All usable memory must be reachable from global variables or from
local variables on goroutine stacks. There is nothing else in Go.
The runtime data structures mentioned earlier in the thread are just
specific global variables.
When we say that a local variable lives on the heap, what that really
means is that the local variable of type T is replaced by a local
variable of type *T, the normal zero-initialization of the local
variable is replaced by new(T), and all references to the variable are
changed to use an additional indirection.
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.
