FAQ
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 ztypes_windows.go

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.

- alan

--

---
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 golang-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Search Discussions

  • Minux at Apr 26, 2014 at 10:41 pm
    Hi Alan,

    If this is your first contribution to Go, please read
    golang.org/doc/contribute.html for
    the process.
    On Sat, Apr 26, 2014 at 6:25 PM, 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 yes.
    I should define any new Win32 API types and/or constants in
    ztypes_windows.go yes.
    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.
    use os/exec to execute a child process, and relay the result of os.Getppid
    back to its parent
    though pipes. you can write a generic test in os for os.Getppid for every
    platform.
    (there are tests that do this in the tree, e.g. pkg/os/exec/exec_test.go)

    One last thing to bear in mind is that the tree is currently frozen for 1.3
    release, so please
    send your CL after Go 1.3 is released, thank you.
    (you can view more about the Go release schedule here:
    golang.org/s/releasesched)

    --

    ---
    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 golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Alan Shreve at Apr 26, 2014 at 10:45 pm
    Awesome, thank you for the pointer to the exec test, that'll be quite helpful.

    - alan
    On Apr 26, 2014, at 4:40 PM, minux wrote:

    Hi Alan,

    If this is your first contribution to Go, please read golang.org/doc/contribute.html for
    the process.

    On Sat, Apr 26, 2014 at 6:25 PM, 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
    yes.

    I should define any new Win32 API types and/or constants in ztypes_windows.go
    yes.

    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.
    use os/exec to execute a child process, and relay the result of os.Getppid back to its parent
    though pipes. you can write a generic test in os for os.Getppid for every platform.
    (there are tests that do this in the tree, e.g. pkg/os/exec/exec_test.go)

    One last thing to bear in mind is that the tree is currently frozen for 1.3 release, so please
    send your CL after Go 1.3 is released, thank you.
    (you can view more about the Go release schedule here: golang.org/s/releasesched)
    --

    ---
    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 golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Brainman at Apr 27, 2014 at 12:36 am
    You should add all windows struct and const into ztypes_windows.go and
    function prototypes to syscall_windows.go, then run:

    cd $GOROOT/src/pkg/syscall
    GOOS=windows GOARCH=386 ./mkall.sh
    GOOS=windows GOARCH=amd64 ./mkall.sh

    on unix or

    cd %GOROOT%\src\pkg\syscall
    mkall_windows.bat 386
    mkall_windows.bat amd64

    on windows (unchecked, I don't have computer now). These scripts will
    update zsyscall_windows_386.go and zsyscall_windows_amd64.go files, then
    you can use new Windows APIs from outside of syscall package.

    Alex

    --

    ---
    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 golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Alan Shreve at Apr 28, 2014 at 3:33 am
    I got this all working and added a test to verify Getppid() across all platform with your suggestion to reuse the child process technique used by os/exec's tests. I'll hold off on submitting the CL until after 1.3 ships per minux's request.

    I just ended up with one question about the implementation:

    The code requires mapping the ProcessEntry32 structure: http://msdn.microsoft.com/en-us/library/windows/desktop/ms684839(v=vs.85).aspx

    Most of the fields in the structure are easy to map because they have explicit sizes. DefaultHeapId, however, is a ULONG_PTR which is 32-bit or 64-bit depending on the architecture. Can I map this as a uintptr and be guaranteed it will be of the proper size, or should I create two separate definitions in ztypes_windows_386.go/ztypes_windows_amd64.go?

    - alan
    On Apr 26, 2014, at 6:36 PM, brainman wrote:

    You should add all windows struct and const into ztypes_windows.go and function prototypes to syscall_windows.go, then run:

    cd $GOROOT/src/pkg/syscall
    GOOS=windows GOARCH=386 ./mkall.sh
    GOOS=windows GOARCH=amd64 ./mkall.sh

    on unix or

    cd %GOROOT%\src\pkg\syscall
    mkall_windows.bat 386
    mkall_windows.bat amd64

    on windows (unchecked, I don't have computer now). These scripts will update zsyscall_windows_386.go and zsyscall_windows_amd64.go files, then you can use new Windows APIs from outside of syscall package.

    Alex

    --

    ---
    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 golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
    --

    ---
    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 golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Minux at Apr 28, 2014 at 3:48 am

    On Sun, Apr 27, 2014 at 11:33 PM, Alan Shreve wrote:

    I got this all working and added a test to verify Getppid() across all
    platform with your suggestion to reuse the child process technique used by
    os/exec’s tests. I’ll hold off on submitting the CL until after 1.3 ships
    per minux’s request.

    I just ended up with one question about the implementation:

    The code requires mapping the ProcessEntry32 structure:
    http://msdn.microsoft.com/en-us/library/windows/desktop/ms684839(v=vs.85).aspx

    Most of the fields in the structure are easy to map because they have
    explicit sizes. DefaultHeapId, however, is a ULONG_PTR which is 32-bit or
    64-bit depending on the architecture. Can I map this as a uintptr and be
    guaranteed it will be of the proper size, or should I create two separate
    definitions in ztypes_windows_386.go/ztypes_windows_amd64.go?
    I think having just one definition helps to ease future maintenance.
    however, if that field could contain genuine pointers, you'd better use
    unsafe.Pointer instead of uintptr,
    because otherwise the precise GC will miss the pointer and collect the
    object it points to.

    --

    ---
    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 golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Alan Shreve at Apr 28, 2014 at 3:58 am
    Okay I prefer that as well as long as the size of uintptr is guaranteed to be 32bit/64bit as appropriate.

    The memory in question is allocated/freed by calls to the win32 API. As far as I understand, Go's GC shouldn't need to know about it.
    On Apr 27, 2014, at 9:48 PM, minux wrote:


    On Sun, Apr 27, 2014 at 11:33 PM, Alan Shreve wrote:
    I got this all working and added a test to verify Getppid() across all platform with your suggestion to reuse the child process technique used by os/exec's tests. I'll hold off on submitting the CL until after 1.3 ships per minux's request.

    I just ended up with one question about the implementation:

    The code requires mapping the ProcessEntry32 structure: http://msdn.microsoft.com/en-us/library/windows/desktop/ms684839(v=vs.85).aspx

    Most of the fields in the structure are easy to map because they have explicit sizes. DefaultHeapId, however, is a ULONG_PTR which is 32-bit or 64-bit depending on the architecture. Can I map this as a uintptr and be guaranteed it will be of the proper size, or should I create two separate definitions in ztypes_windows_386.go/ztypes_windows_amd64.go?
    I think having just one definition helps to ease future maintenance.
    however, if that field could contain genuine pointers, you'd better use unsafe.Pointer instead of uintptr,
    because otherwise the precise GC will miss the pointer and collect the object it points to.
    --

    ---
    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 golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Minux at Apr 28, 2014 at 4:00 am

    On Sun, Apr 27, 2014 at 11:58 PM, Alan Shreve wrote:

    Okay I prefer that as well as long as the size of uintptr is guaranteed to
    be 32bit/64bit as appropriate.

    The memory in question is allocated/freed by calls to the win32 API. As
    far as I understand, Go’s GC shouldn’t need to know about it.
    Alright, if it doesn't point to Go heap, then uintptr is perfectly fine.
    (you might want to comment about this so that reviewers don't need to look
    it up.)

    --

    ---
    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 golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Jjeffery 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
    ztypes_windows.go

    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.

    - alan
    --
    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 golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-dev @
categoriesgo
postedApr 26, '14 at 10:25p
activeJun 30, '14 at 12:25a
posts9
users4
websitegolang.org

People

Translate

site design / logo © 2022 Grokbase