On Tue, Oct 24, 2023 at 09:58:22AM -0700, 'Bryan C. Mills' via golang-nuts wrote: > If a C thread calls into Go, the goroutine processing that call (and only > that goroutine) will run on the C thread. The Go runtime will initialize
Is this thanks to the `lockOSThread` call in function `cgocallbackg` of https://github.com/golang/go/blob/master/src/runtime/cgocall.go? > any of its own per-thread state for that thread as needed. If a goroutine > calls into C, and that C thread calls back into Go, I believe that the > C-to-Go call will be on the same goroutine as the Go-to-C call. This is great news. > So if you have a chain of cross-language calls (say, Go to C to Go to C to > Go), that should still only consume one OS thread in total. That's good. I found it also explained here https://groups.google.com/g/golang-nuts/c/8Lx2TUzeXQE/m/3yl0A-wPEAAJ. > > On the other hand, if you have a goroutine without any C call frames, and > that goroutine may have thread-local data for the Python interpreter, you > should explicitly call LockOSThread on that goroutine — and never unlock > it! — to avoid that data migrating unexpectedly to another goroutine. > See https://go.dev/issue/20395. That's a very interesting and eye opening link, thanks a lot. Dom > > On Monday, October 23, 2023 at 8:34:28 AM UTC-4 Domenico Andreoli wrote: > > > Hi, > > > > I'm writing a Go library to embed/extend CPython (Pygolo > > <https://gitlab.com/pygolo/py>). CPython uses thread local storage and > > therefore I need to care about pinning goroutines to OS threads accordingly. > > > > It's pretty much clear that when the Python interpreter is embedded it can > > be accessed only from one goroutine and that such goroutine must be locked > > to an OS thread all the time. > > > > It's possible to create Python thread states and allow multiple threads to > > access the interpreter, therefore other goroutines - if locked to an OS > > thread - can access the interpreter (modulo Python GIL). > > > > It's also clear that if the Python interpreter calls back a Go function it > > will happen from one of the locked threads of above and therefore nothing > > special needs to be done on the Go side. > > > > Or not? If a thread is locked no other goroutines are allowed to run as > > per documentation of LockOSThread, so on which goroutine the Go callback > > will actually run? > > > > Different story is when Go is used to extend the Python interpreter, when > > Go calls are happening in a thread not owned by the Go runtime. Here I have > > some doubts, I think I read something about cgo locking threads of Go > > callbacks but I can't find it any more. > > > > I guess that at the first Go call cgo initializes the Go runtime and > > suddenly a few threads and goroutines spawn to life but how the goroutine > > scheduling works when C is in control of the calling threads? > > > > Is it possible that multiple goroutines get scheduled on the caller C > > thread? > > > > Are Go callbacks goroutines reused? If not and I leave a Go callback > > goroutine locked to a thread, is the calling C thread going to be killed, > > as per documentation of LockOSThread? > > > > Thanks in advance for any clarification. > > > > Regards, > > Dom -- rsa4096: 3B10 0CA1 8674 ACBA B4FE FCD2 CE5B CF17 9960 DE13 ed25519: FFB4 0CC3 7F2E 091D F7DA 356E CC79 2832 ED38 CB05 -- 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/ZTkfF4XpOdTpQzA4%40localhost.
