digging into the source code in runtime/cgo/callbacks.go, suggests that indeed it does spawn a new thread for starting up the library (see code below). Thus, the solution was to just call the initialization for the gui thread *after* the library has been loaded and initialized, which indeed is from the main thread. Now all I need to do is to figure out how to get python to keep running in a separate thread while its main thread is blocked in the event loop from which it never returns..
- Randy // Creates a new system thread without updating any Go state. // // This method is invoked during shared library loading to create a new OS // thread to perform the runtime initialization. This method is similar to // _cgo_sys_thread_start except that it doesn't update any Go state. //go:cgo_import_static x_cgo_sys_thread_create //go:linkname x_cgo_sys_thread_create x_cgo_sys_thread_create //go:linkname _cgo_sys_thread_create _cgo_sys_thread_create var x_cgo_sys_thread_create byte var _cgo_sys_thread_create = &x_cgo_sys_thread_create // Notifies that the runtime has been initialized. // // We currently block at every CGO entry point (via _cgo_wait_runtime_init_done) // to ensure that the runtime has been initialized before the CGO call is // executed. This is necessary for shared libraries where we kickoff runtime // initialization in a separate thread and return without waiting for this // thread to complete the init. //go:cgo_import_static x_cgo_notify_runtime_init_done //go:linkname x_cgo_notify_runtime_init_done x_cgo_notify_runtime_init_done //go:linkname _cgo_notify_runtime_init_done _cgo_notify_runtime_init_done var x_cgo_notify_runtime_init_done byte var _cgo_notify_runtime_init_done = &x_cgo_notify_runtime_init_done > On Feb 25, 2019, at 8:13 PM, Kurtis Rader <kra...@skepticism.us> wrote: > > On Mon, Feb 25, 2019 at 6:03 PM Randall O'Reilly <rcoreil...@gmail.com> wrote: > Kurtis — thanks for the suggestion — I had assumed that python always just > runs in the main thread, and when I added this code to my python script, it > shows that it is indeed running in the main thread > > I probably assumed too much when reading your original problem statement. > Python code always run in the main thread, as far as I know, unless you have > used the `threading` module, either directly or indirectly, to spawn > additional threads. The wording of your original problem statement implied > you were calling a Go function from python. In which case that Go function > should execute on the main thread if you haven't explicitly created > additional threads from the main python thread. But you can't assume that > loading your Go module from the python main thread will ensure the Go > functions execute on the main thread. > > I've worked a lot with C++ code that utilizes threads and which is loaded by > a python program. But that doesn't involve anything like the Go M:N go > routine to thread scheduler. There are probably subtleties in mixing the two > languages that I'm not familiar with. > > -- > Kurtis Rader > Caretaker of the exceptional canines Junior and Hank -- 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. For more options, visit https://groups.google.com/d/optout.
