On Wed, 27 Aug 2025, Aleksa Sarai wrote: > On 2025-08-27, Alexander Monakov <amonakov@xxxxxxxxx> wrote: > > > Frankly, in such situation I would spawn a thread for that, did unshare(CLONE_FILES) > > > in it, replaced the binary and buggered off, with parent waiting for it to complete. > > > > Good to know, but it doesn't sound very efficient (and like something that could be > > integrated in Go runtime). > > Can't you create a goroutine, runtime.LockOSThread, > unshare(CLONE_FILES), do the work, and then return -- without > runtime.UnlockOSThread (to kill the thread and stop it from being used > by other Go code)? Or does that not work in stdlib? Again, with regards to Go backstory, I'm just the messenger. But were I a Go runtime implementor, I'm afraid no, I wouldn't be able to do that, because while the file is being written, it's done with normal I/O APIs. The runtime has no way to look in the future and anticipate that the file currently being written will be execve'd. My first priority here is not to dig up alternative solutions to the ETXTBSY problem. I'm asking about a race window in __fput. Alexander
