runtime shutdown internal routines? / locating Go runtime threads

[Jason E. Aten]

Is there code internal to the runtime that shuts down all of its threads at the end of the process, or does it just

rely upon the OS to do the cleanup?

I'm asking for a Windows DLL unload situation, hoping to be able to unmap the runtimes memory without having it crash the main program on DLL unload.

As a workaround last year I pinned the DLL permanently into Windows memory, but that hack is starting to crack around the edges.

If not, I suppose I can just try to manually kill them with the windows API, TerminateThread(); if I can find their handles.

Which begs the question... is there a way to locate the Go runtime/all user goroutine threads (in Windows)?

Thanks!

[brainman]

What is your problem?

If you fill in this

http://golang.org/issue/new

Some might help you.

Alex

[Ian Lance Taylor]

On Thu, Mar 5, 2020 at 8:35 PM Jason E. Aten <j.e....@gmail.com> wrote:
>
> Is there code internal to the runtime that shuts down all of its threads at the end of the process, or does it just
> rely upon the OS to do the cleanup?

It just relies on the OS.

> I'm asking for a Windows DLL unload situation, hoping to be able to unmap the runtimes memory without having it crash the main program on DLL unload.
> As a workaround last year I pinned the DLL permanently into Windows memory, but that hack is starting to crack around the edges.
>
> If not, I suppose I can just try to manually kill them with the windows API, TerminateThread(); if I can find their handles.
> Which begs the question... is there a way to locate the Go runtime/all user goroutine threads (in Windows)?

All the threads can be found on the list that starts at runtime.allm,
linked through the alllink field. On WIndows, the thread handle can
be found in the m's thread field, protected by the threadLock field.

There's no particular guarantee that it's safe to terminate all the
threads, but I can't offhand think of anything that would break as
long as you are careful to get all of them, and, of course, careful to
never call into Go code while or after killing the threads.

Ian