Proposal Details

Summary

I believe that especially when go code is being run as a C library, there should be optional detection and warning for actions that can cause a process to hang.

Using the fork() issue detailed in #53806 as an example, this might look like:
An optional build argument would trigger the runtime to check the process PID before it performs calls to the goroutine scheduler that might hang. If the PID changes, a fork occurred, and either a panic or a simple warning to stderr is performed.

Background

Recently I switched a codebase from github.com/mattn/go-sqlite3, to crawshaw.io/sqlite/sqlitex for accessing a file sqlite3 db. The codebase produces a couple go programs and a c-shared library that is used by a legacy app. Upon testing this change the legacy app's child processes hung. After hours of ruling out sqlite3, I finally saw #53806. I am assuming that because mattn does not use goroutines, it avoided the issue while crawshaw used goroutines to manage connection pools and hung the child processes.

Reading about the core issue, fork only copies a single thread, it is pretty easy to see why the issue occurs. Go also does a great job of making it hard to fork within Go code. The problem really is that C programs are already calling fork() and the Go code may or may not hang because of it. This really hides the root cause of the issue and I am hoping that this proposal makes it more clear.