[Linux] SysProcAttr: CloneFlags versus UnshareFlags w/ CLONE_NEWPID

[TheDiveO]

I want to start a new child process in a new PID namespace. Looking at syscall.SysProcAttr there are both "Cloneflags" and "Unshareflags". Beyond the obviously less friendly and not really helpful answer "because there's clone(2) and unshare(2)", what is the reason for not being able to go with just the Cloneflags, especially when it comes to unsharing (sic!) namespaces as part of clone(2)?

Initially, I used Unshareflags with unix.CLONE_NEWPID and this caused "weird" behavior when the child process happened to be a Go binary: runtime/cgo not being able to create a pthread and then some other part of the runtime spilling its guts including CPU registers, or alternatively a similar cannot create new thread (errno? = 22) and also CPU register guts.

Only after some time I realized I might try to move unix.CLONE_NEWPID to Cloneflags instead ... and instant success. While I have a working solution, I would like to understand the rationale(s) between doing "some" things (which?) better not in clone(2), but in the child's unshare(2) before replacing the child copy with the intended binary? 

[Ian Lance Taylor]

If you set Unshareflags then the child process will call unshare with
those flags. If Unshareflags is left as zero then the child process
will not call unshare.

The parent process will always call clone (or clone3), and it will
pass Cloneflags when it does.

Perhaps everything that can be done with Unshareflags can be done with
Cloneflags. It's possible that it was a mistake to add Unshareflags.

Ian