|| at Jun 30, 2014 at 12:25 am
I've just come across this post, I know it's pretty old. I just thought I
might mention that although this implementation is about as good an
implementation you can get of Getppid on Windows, it does have a signficant
difference in behaviour to the Un*x implementations. This function will
return the parent's PID even after the parent has terminated, in contrast
to the Un*x implementations, which all return 1 if the original parent
process has terminated.
To make things worse, Windows likes to re-use PIDs quite quickly, so on
Windows Getppid could return the PID of a running process which did not
start the process.
AFAIK, there is no way around this on Windows, so os.Getppid() would need
to be used with extreme caution on Windows. The longer the process has been
running, the higher the possibility of it returning a misleading result.
On Sunday, 27 April 2014 08:25:47 UTC+10, Alan Shreve wrote:
Just recently I needed a function which would pull out the parent process
information on Windows. While implementing this, I noticed that there is no
implementation for os.Getppid() on windows so I thought I’d contribute my
implementation. Before I wrote it up, I just wanted to verify a few things:
I should define the new syscalls by writing comments in
syscall/syscall_windows.go and then run the mksyscall_windows.pl script
to generate the functions
I should define any new Win32 API types and/or constants in
The implementation for getting the parent process identifier on windows is
not a completely trivial exercise. I’m not entirely certain how to go about
testing this functionality. How do you test your use of the Win32 API? It
doesn’t look like there are any tests around getppid on any platforms.
You received this message because you are subscribed to the Google Groups "golang-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to firstname.lastname@example.org.
For more options, visit https://groups.google.com/d/optout.