[slime-devel] Patch for ABCL GETPID implementation
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@gmx.at> "[T]his is not a disentanglement from, but a progressive knotting into." diff -r 0c36088c65c0 swank-abcl.lisp --- a/swank-abcl.lisp Wed Jan 02 17:02:52 2008 +0100 +++ b/swank-abcl.lisp Wed Jan 23 12:09:39 2008 +0100 @@ -143,8 +143,7 @@ (funcall fn)) (defimplementation getpid () - (if (not (find :unix *features*)) - 0 + (handler-case (let* ((runtime (java:jstatic "getRuntime" "java.lang.Runtime")) (command @@ -153,8 +152,8 @@ (runtime-exec-jmethod ;; Complicated because java.lang.Runtime.exec() is ;; overloaded on a non-primitive type (array of - ;; java.lang.String), so we have to use the actual parameter - ;; instance to get java.lang.Class + ;; java.lang.String), so we have to use the actual + ;; parameter instance to get java.lang.Class (java:jmethod "java.lang.Runtime" "exec" (java:jcall (java:jmethod "java.lang.Object" "getClass") @@ -162,19 +161,19 @@ (process (java:jcall runtime-exec-jmethod runtime command)) (output - (java:jcall (java:jmethod "java.lang.Process" "getInputStream") + (java:jcall (java:jmethod "java.lang.Process" "getInputStream") process))) - (java:jcall (java:jmethod "java.lang.Process" "waitFor") process) - (loop - :with b - :do (setq b - (java:jcall (java:jmethod "java.io.InputStream" "read") - output)) - :until (member b '(-1 #x0a)) ; Either EOF or LF - :collecting (code-char b) :into result - :finally (return - (values - (parse-integer (coerce result 'string)))))))) + (java:jcall (java:jmethod "java.lang.Process" "waitFor") + process) + (loop :with b :do + (setq b + (java:jcall (java:jmethod "java.io.InputStream" "read") + output)) + :until (member b '(-1 #x0a)) ; Either EOF or LF + :collecting (code-char b) :into result + :finally (return + (parse-integer (coerce result 'string))))) + (t () 0))) (defimplementation lisp-implementation-type-name () "armedbear")
* 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@gmx.at> "[T]his is not a disentanglement from, but a progressive knotting into."
* 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.
participants (2)
-
Helmut Eller -
Mark Evenson