While exploring more of the proc.go code I noticed that my original question somehow didn't fully reflect what I'm wondering about: what happens in the following situation...? Are all tasks/threads really equal?
- a non-main G42 goroutine gets scheduled onto the main thread/leader task, which in Linux represents the whole process. What I called also T0 in the discussion above. - G42 calls runtime.LockOSThread. - G42 terminates/ends. What now? Terminating T0 doesn't look like a great idea at second look: for instance, as I mentioned above, this causes some problems further down the road, such as things in the procfs for this process becoming inacessible. Is there a way to trick(?) a non-main goroutine onto T0 as an experiment? On Thursday, May 26, 2022 at 9:54:52 PM UTC+2 TheDiveO wrote: > Ian, thank you very much! Found it and am now trying to somehow get my > head around it! > > On Thursday, May 26, 2022 at 9:46:26 PM UTC+2 Ian Lance Taylor wrote: > >> On Thu, May 26, 2022 at 12:08 PM TheDiveO <harald....@gmx.net> wrote: >> >> > >> > On Thursday, May 26, 2022 at 8:51:49 PM UTC+2 Ian Lance Taylor wrote: >> >> >> >> If the scheduler is running on a goroutine locked using >> >> runtime.LockOSThread and needs to start a new thread, it does so by >> >> asking a template thread to create it. The template thread doesn't do >> >> anything other than create new threads, so it should be in a clean >> >> state. >> > >> > >> > Do you per chance have a link to where I can find the template thread >> handling in the runtime scheduler? >> >> Search for [tT]emplateThread in $GOROOT/src/runtime/proc.go. >> >> 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/059f283c-2c94-4c9c-a4cf-a8c5e35f988fn%40googlegroups.com.
