Golang specification :

The operator " go

" starts the execution of the function call as an independent parallel flow of control or goroutine

in the same address space .

Can anyone explain to me the basics of the problem?

"Address space" is a general term that can be applied to many contexts:

Address spaces are created by combining sufficiently uniquely identified qualifiers to make an address unambiguous (within a specific address space)

Dave Cheney's presentation Five Things That Make Go fast "illustrates a basic problem goroutine solves in the same process address space: stack management .

Dave qualifies "address space" by saying first from the stream:

Since a process switch can occur at any time during the execution of a process, the operating system must store the contents of all these registers because it does not know which ones are currently in use.

This leads to the development of threads that are conceptually the same as processes, but use the same memory space .

(this is about memory)

Dave then illustrates the stack in the process address space (process controlled addresses):

Traditionally, inside the address space of a process,

• the heap is at the bottom of memory, just above the program (text) and growing up.
• The stack is at the top of the virtual address space and grows downward.

See also " What and where are the stack and heap? "

Problem:

Because overwriting the heap and stack on top of each other would be catastrophic, the operating system usually arranges to allocate an area of ​​non-volatile memory between the stack and heap to ensure that if they collide, the program will abort.

With threads that can limit the heap size of a process:

as the number of threads in your program increases, the amount of available address space decreases.

goroutine takes a different approach while keeping the same process address space:

what about the stack requirements of these goroutines?

Instead of using guard pages, the Go compiler inserts a check as part of every function call to check if there is enough stack for the function being invoked. If it doesn't, the runtime may allocate more stack space.

Because of this check, the original goroutines stack can be made much smaller, which in turn allows Go programmers to handle goroutines as cheap resources.

Go 1.3 introduces a new way to manage these stacks:

Instead of adding and removing additional stack segments, if the goroutine stack is too small, a new, higher stack will be allocated.

The contents of the old stacks are copied onto the new stack, then goroutine continues with its new large stack.

After the first call to H, the stack will be large enough that checking for free stack space is always successful.