On Wed, Aug 27, 2025 at 10:22:14AM +0300, Alexander Monakov wrote: > > On Tue, 26 Aug 2025, Al Viro wrote: > > > Egads... Let me get it straight - you have a bunch of threads sharing descriptor > > tables and some of them are forking (or cloning without shared descriptor tables) > > while that is going on? > > I suppose if they could start a new process in a more straightforward manner, > they would. But you cannot start a new process without fork. Anyway, I'm but > a messenger here: the problem has been hit by various people in the Go community > (and by Go team itself, at least twice). Here I'm asking about a potential > shortcoming in __fput that exacerbates the problem. I'm assuming that the problem is showing up in real life when users run a go problem using "go run" where the golang compiler freshly writes the executable, and then fork/exec's the binary. And using multiple threads sharing descriptor tables was just to make a reliable reproducer? - Ted