On Thu, Mar 5, 2020 at 8:35 PM Jason E. Aten <j.e.a...@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

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAOyqgcVH%2BTO4QEr%3Dw2jpHaK%2BbbY8j_zW06%2BeeHR%2Bqe82W2d2CQ%40mail.gmail.com.

Reply via email to