3 ms·

Not true. System stacks are system allocated. See my reply above.

• 4ad 12y ago
  Thanks for your note, but I'm confused by your statement. Take Linux go/src/runtime/os_linux.c:/^runtime·newosproc. It passes the already-allocated stack to clone(2). runtime·newosproc is called from go/src/runtime/proc.c:/^newm, which uses runtime·allocm to allocate a M. go/src/runtime/proc.c:/^runtime·allocm allocates this memory using runtime·malg on everything except Solaris, Windows, Plan 9, or when using cgo. The comment even reads: // In case of cgo or Solaris, pthread_create will make us a stack. // Windows and Plan 9 will layout sched stack on OS stack. For that class of systems, runtime·newosproc (or _cgo_sys_thread_start) indeed does use the system stacks, but that's what I said too. Let's take a look at runtime·malg again. runtime·malg calls go/src/runtime/stack.c:^/runtime·stackalloc which uses runtime·sysAlloc to allocate memory. Moving back to Linux, go/src/runtime/mem_linux.c:/^runtime·sysAlloc just calls mmap(2). So, the answer to "who allocates system stacks" seems to be "it depends", but I already qualified this in my original answer (omitting cgo; sorry about that). Now, is there anything wrong in my description?
  • rsc 12y ago
    It is true that when cgo and therefore pthreads is not involved, Go allocates all the stacks. But then the question of where 'system code' runs is not terribly relevant: it doesn't.