nickeygit

> We could also roll our own handler IDs and store them in a map. maybe with https://pkg.go.dev/runtime/[email protected]#Handle , I wanted to try that out anyways Just wondering if you...

> I experimented with a change: And I've used cgo.Handle (great thing!) - and this allowed to eliminate closures map. But have not relaxed the issue at all. The test...

So, cgo is being initialized somewhere earlier at some thread before goroutine is locked to it. Where? The only thing I see so far - is here: ``` > ldd...

> but cgo threads should be already locked. (I may be wrong) Nope, this happens on demand only: CGO normal thread in dump: ``` goroutine 7 [running]: main.test_func_pipe_and_closure() /app/test1_os_thread/test1_os_thread.go:175 +0xb8...

> I think the HandlerDisconnect crash is a result of some wrong order of unref/ closure invalidation done by go-gst. We have no Closure Go class/struct wrapper - so no...

Another step. My test is running for an hour already. No errors/asserts. I was thinking, I've covered all the goroutines with LockOSThread(). But then a thought came: the finalizers -...

Oh well, still asserting/crashing sometimes... Searched the web and found an interesting thing about the problem. It's a known issue for some graphics libraries (like SDL or OpenGL) - they...

> The unref is called by the GC mostly and I have a feeling that locking GC to threads has some bigger implications. Yes, but anyway, this is not completely...

> @nickeygit sorry if it sounds like I want to block your suggestion. It is just that you are suggesting a big change and I cannot fully grasp the consequences....

> what is the definition of "main thread" here? Is it the thread with the glib main loop or the main application thread? These might not be the same. Since...