proposal: os/exec: add an API to exec over the current process

[bcmills]

Go programs cannot currently call syscall.Exec safely (see #18146).

However, it is sometimes useful for a Go program to be able to execute some other command without retaining resources (such as memory) for a Go program that has no further work to do. syscall.Exec, although error-prone in Go, is the usual way to do that on a Unix-like platform.

If we can find a way to implement portable Exec-like functionality compatible with the Go runtime, it would be nice to have an API for that as part of the standard library (perhaps in the os/exec package). If it cannot be done portably, perhaps we could add something to x/sys/unix?

[bradfitz]

x/sys/unix sounds preferable.

[ianlancetaylor]

If we can find a way to implement it portably, then depending on what we do, we should consider simply doing that in syscall.Exec.

But perhaps it would be enough to simply retry EGAIN errors on pthread_create in runtime/cgo.

[kevinburke]

(FWIW I tried to use syscall.Exec recently and found it pretty confusing as someone who has previously typed exec in the terminal, but never used the execve syscall, in terms of how it expected arguments (setting PATH in the 3rd argument won't matter for finding the executable), so I think there is some potential for a usability gain in addition to fixing the underlying correctness problem. See for example https://go-review.googlesource.com/#/c/29121/2)

[rsc]

It's not possible to do portably, right? The concept doesn't exist in Windows, and it's not allowed in multithreaded (= all Go) programs on macOS. That's why there's only syscall.Exec.

It seems like if syscall.Exec has bugs, they should be fixed (like #18146, which Ian is fixing). But it's in syscall precisely because it's not portable.

[rsc]

It sounds like we should decline this proposal. Objections?

[bcmills]

I'm ok with declining.