os: TestGetppid fails on plan9

[alexbrainman]

--- FAIL: TestGetppid (0.02 seconds)
    os_test.go:1318: Child process reports parent process id '0', expected '917122'

Alex

[gopherbot]

Comment 1 by lucio.dere:

Curiously, the C routine for getpid() in runtime/os_plan9.c checks for both leading
spaces and tabs, whereas the Go version in syscall/syscall_plan9.go restricts itself to
checking the contents of #c/pid for leading spaces.
Looking at the code for getppid() in syscall/sycall_plan9.go, I cannot see any other
distinctive features (there is no room for them) that could explain why one syscall
succeeds and the other fails.
That basically says: either tabs are important or the absence of getppid() in
runtime/os_plan9.c is significant (but the latter is really unlikely).
Lucio.

[0intro]

Comment 2:

It seems Getppid() always return 0 on Plan 9 in this test.
This is rather surprising, since writing a simple program calling
os.Getppid works as expected.
term% GO_WANT_HELPER_PROCESS=1 go test -run TestGetppid
0
ok      os  0.034s
http://play.golang.org/p/npUUya7FmI
term% go run getppid.go
7137

[ality]

Comment 3:

This is an artifact of the way we fork runtime procs.
RFNOWAIT disassociates the child from the parent so
if the current goroutine is running on a proc that isn't
the initial runtime proc, reads from #c/ppid will always
return 0.
Since the runtime doesn't use threads on Plan 9, we need
to decide precisely what the semantics of os.Getpid and
os.Getppid should be for user code.
Thoughts?

[gopherbot]

Comment 4 by lucio.dere:

For the purposes of this test, the result of invoking geppid have to match what the
Unixes deliver.  If this isn't implicit for Plan 9, then the problem has already been
resolved by removing the test.
Of course, only until some application assumes a working os.Getppid() and the Plan 9
implementation gets bitten (we have an outstanding issue in this vein that Gustavo
Niemeyer promised to look at: "undefined: syscall.WaitStatus" when trying his new "pipe"
package).
It seems to me that either we ensure that the PID syscalls are consistent with Unix
(Posix?) expectations across their semantic effect, or we declare Plan 9 anomalous and
make sure this is carefully and clearly documented so that we don't get caught again.
Lastly, maybe I missed a suggestion that we put on a thinking cap and figure what
combination of flags will produce Unix-y behaviour for getpid and getppid; I can't think
that anyone will know this better than Rob and Russ.
Lucio.

[ality]

Comment 6:

Lucio,
The syscall package is os-dependent: there is no guarantee that
the API is the same for all supported operating systems. I sent
a CL years ago—one that I'd like to eventually revise—with the
intention of completely stripping out all the Unix compatibility
stuff from the Plan 9 syscall package. It was put there early in
the life of the port only for expediency and should be removed.
This is unrelated to the issue at hand, though, so if you want
to discuss it more we should probably move to the mailing list.