On Wed, Jun 1, 2022 at 10:45 AM TheDiveO <harald.albre...@gmx.net> wrote: > > 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.
Can you point to some documentation about this problem, or show a program where it causes problems. > Is there a way to trick(?) a non-main goroutine onto T0 as an experiment? I'm not sure what a "non-main goroutine" is. All goroutines are basically equivalent. Assuming you mean the initial goroutine, you can lock that to the initial thread by calling runtime.LockOSThread in an init function. That should wind up calling the main function with a goroutine locked to the initial thread. Then you could, for example, start a new goroutine and then let the initial goroutine exit. 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/CAOyqgcVPgMHTHbuZh22SFhu-93Bn2gHn9K%2B3nMnAGDN4VU5GDA%40mail.gmail.com.
