Apparently PPID for the parent process id is not a standard feature of the Bourne shell (or at least it isn't present under solaris-5.11).
Attached is a patch to my ABCL GETPID implementation that uses HANDLER-CASE to return '0' if any error is raised in attempting to getpid().
* Mark Evenson [2008-01-23 12:18+0100] writes:
Apparently PPID for the parent process id is not a standard feature of the Bourne shell (or at least it isn't present under solaris-5.11).
Attached is a patch to my ABCL GETPID implementation that uses HANDLER-CASE to return '0' if any error is raised in attempting to getpid().
I think we could always return 0 and get rid of the entire mess. The pid is only needed for implementations for which we use Unix signals to interrupt the Lisp process. For ABCL we use threads and not signals.
Any objections to that?
Helmut Eller wrote:
- Mark Evenson [2008-01-23 12:18+0100] writes:
Apparently PPID for the parent process id is not a standard feature of the Bourne shell (or at least it isn't present under solaris-5.11).
Attached is a patch to my ABCL GETPID implementation that uses HANDLER-CASE to return '0' if any error is raised in attempting to getpid().
I think we could always return 0 and get rid of the entire mess. The pid is only needed for implementations for which we use Unix signals to interrupt the Lisp process. For ABCL we use threads and not signals.
[Sorry about the late response].
A possible Use Case for leaving the PID code in: knowing the PID of the JVM that the SLIME it attached to allows one to distinguish which JVM has "gone off the reservation" when running multiple instances of ABCL. It also allows debugging/profiling tools to be quickly attached to the running instance. Of course, the PID can be found by other means, but it does seem somewhat useful.
But, it's basically your codebase, so if you think the GETPID DEFIMPLEMENTATION is a mess, you're going to remove it aren't you?
Thanks for listening,
* Mark Evenson [2008-02-20 10:07+0100] writes:
A possible Use Case for leaving the PID code in: knowing the PID of the JVM that the SLIME it attached to allows one to distinguish which JVM has "gone off the reservation" when running multiple instances of ABCL. It also allows debugging/profiling tools to be quickly attached to the running instance. Of course, the PID can be found by other means, but it does seem somewhat useful.
But, it's basically your codebase, so if you think the GETPID DEFIMPLEMENTATION is a mess, you're going to remove it aren't you?
Well, I left it there. But I'm still wondering why finding the pid is so hard on the JVM.
Helmut.
-
Helmut Eller -
Mark Evenson