The parent process id (ppid) of a process cannot be changed outside of the kernel; there is no setppid system call. The kernel will only change the ppid to (pid) 1 after the processes parent has terminated - if the process did not respond to a signal that the parent was terminated. For this to happen, the process needs to have ignored various signals (SIGHUP, SIGTERM, etc.) beforehand.
screen(1) has a very elegant means of handling detaching and reattaching. When you first start screen, you are actually starting a user interface (ui), which by default will create a daemon (the session manager). This daemon has no terminal associated with it, a new process group (setpgrp(2)), a new session id (setsid(2)). The daemon, running as SCREEN, will then create subprocesses connected to pseudo-terminals (pty), then multiplexes the data from the ptys and the ui (screen). The subprocesses think they are talking with a real terminal.
If the ui screen terminates, the daemon SCREEN will still be running, buffering data, handling signals, waiting for a new ui, etc. because it is a different process group and in its own session. When you reattach with a new ui screen, then the daemon will continue to multiplex as it was doing before. The daemon will run continue running until all subprocesses terminate, is killed, a fatal bug is encountered or the host reboots.
valgrind will give you this information, along with a number of other statistics on memory use (and it will tell you about memory leaks etc.). It will slow the program down somewhat, but since yours is a short-lived process it shouldn't be an issue.
Here's example output from running ls:
==7051==
==7051== HEAP SUMMARY:
==7051== in use at exit: 351,689 bytes in 838 blocks
==7051== total heap usage: 1,049 allocs, 211 frees, 688,325 bytes allocated
==7051==
==7051== LEAK SUMMARY:
==7051== definitely lost: 0 bytes in 0 blocks
==7051== indirectly lost: 0 bytes in 0 blocks
==7051== possibly lost: 0 bytes in 0 blocks
==7051== still reachable: 351,689 bytes in 838 blocks
==7051== suppressed: 0 bytes in 0 blocks
==7051== Rerun with --leak-check=full to see details of leaked memory
==7051==
==7051== For counts of detected and suppressed errors, rerun with: -v
==7051== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
The specific information you're looking for is given by the "total heap usage" line.
Best Answer
On Linux, you can find the maximum PID value for your system with this:
This value can also be written using the same file, however the value can only be extended up to a theoretical maximum of 32768 for 32 bit systems or 4194304 for 64 bit:
It seems to be normative practice on most 64 bit systems to set this value to the same value as found on 32 bit systems, but this is by convention rather than a requirement.
From
man 5 proc:And no, you cannot change the PID of a running process. It gets assigned as a sequential number by the kernel at the time the process starts and that is it's identifier from that time on. The only thing you could do to get a new one is have your code fork a new process and terminate the old one.