The old UNIX C function waitpid teaches us that a process can basically be in one of five states:
Few lisp implementations of common lisp expose all this completely through a single function named process-status. One can select a few helpful subquestions, though:
Is the process :running:, :stopped: or :continued: (and thus alive)?
If the process is no longer alive, did it exit or signal and which code?
The former would be answered by the function process-alive-p which some implementations provide; the latter second would answered by a function wait-process.
Because a portability layer like UIOP would have a very hard time giving out reliable process-status information, such a function is called %process-statatus in UIOP and not exported. Instead, the user is hoped to get as much as possible done though the use of the
portable functions uiop:process-alive-p and uiop:wait-process. Here's how:
We take the example of two separate processes, one of which is terminated via signal 15 (SIGTERM), while the other is allowed to exit and does so with an exit status of 143.
This combination of numbers was unintentionally chosen such because dying from signal 15 is typically reported as exiting with exit-code 143 = 128 + 15. On many implementations, we can actually decide these cases, though, which might be of interest to the user.
All of this is illustrated by blocks that look like this in the following output:
The leading T/NIL corresponds to what uiop:process-alive-p reports for each process. At the top we have the the one that tirst ran and was then terminated by signal 15. At the bottom, we have the process that exited with code 143 of its own volition. Finally, the right column of the table tells us that %process-status is left entirely unimplemented on this implementation (abcl-1.5.0-fasl43-linux-x64). But nearly all implementation perform better in this department; take a look at this, for example:
Here we see that sbcl-1.3.21-linux-x64 does implement %process-status quite well and it can also distinguish the cases "signaled with code 15" and "exited with code 143" through the one/two numbers uiop:wait-process returns.
Here now, is the complete code:
The output from running the test on a few implementations