gnu clisp foreign function interface with LINUX package

wje_lq · 03-06-2011, 12:36 PM

I'm not using (linux:waitpid) correctly. The function call actually waits for the child process, as I want it to; the problem is that it doesn't return the correct values, which would be the pid of the child process and the returned status (which should be 256, because the child process is exiting with status 1).

Two questions:

How should I fix this?
How do I read, and write, errno?

Code:

 1 ; fork-waitpid
 2 ;
 3 (defun do-child ()
 4    (format t "entering child process~%")
 5    (sleep 5)
 6    (format t "exiting child process~%")
 7    (quit 1))
 8 :
 9 (defun do-parent()
10    (format t "parent sees that child process is process ~a~%" the-pid)
11    (setq pid-input-to-function -1)
12    (setq waitpid-options 0)
13    (setq something (multiple-value-list
14       (linux:waitpid pid-input-to-function waitpid-options)))
15    (format t "first  returned value: ~a~%second returned value: ~a~%"
16       (car something)
17       (cadr something))
18    (format t "good-bye!~%"))
19 ;
20 (setq the-pid (linux:fork))
21 (if (= the-pid 0)
22    (do-child)
23    (do-parent))
entering child process
parent sees that child process is process 11599
exiting child process
first  returned value: -1
second returned value: 0
good-bye!

ntubski · 03-06-2011, 01:39 PM

Where is linux:waitpid defined? I can only find POSIX:WAIT.

Quote:

How do I read, and write, errno?

See Foreign variables

wje_lq · 03-06-2011, 03:59 PM

POSIX, LINUX, and UNIX all refer to the same package; two of them are nicknames. But I'll stick to POSIX instead of LINUX for this thread.

Thanks for the link. I'd read it, but it didn't hurt to go over it again. I don't think I'm quite understanding it.

Let's say I want to create a C-style variable. Let's start with something simple: an integer.

Code:

home:~/lisp/experiments$ clisp -q
[1]> (ffi:def-c-var wje-child-pid)

*** - FFI:DEF-C-VAR: :TYPE option missing in (FFI:DEF-C-VAR WJE-CHILD-PID)
The following restarts are available:
ABORT          :R1      Abort main loop
Break 1 [2]> :r1
[3]> (ffi:def-c-var wje-child-pid :type ffi:int)

*** - Invalid option in (FFI:DEF-C-VAR WJE-CHILD-PID :TYPE FFI:INT): :TYPE
The following restarts are available:
ABORT          :R1      Abort main loop
Break 1 [4]> (quit)
home:~/lisp/experiments$

What did I do wrong here?

ntubski · 03-06-2011, 07:30 PM

Quote:

Originally Posted by wje_lq

POSIX, LINUX, and UNIX all refer to the same package; two of them are nicknames. But I'll stick to POSIX instead of LINUX for this thread.

Turns out they don't, it looks like LINUX is a currently undocumented module:

Code:

CL-USER> (package-nicknames 'linux)
("GLIBC" "UNIX")
CL-USER> (package-nicknames 'posix)
("OS")

Also

Code:

CL-USER> linux:errno
0

Quote:

Let's say I want to create a C-style variable. Let's start with something simple: an integer.

Code:

home:~/lisp/experiments$ clisp -q
[1]> (ffi:def-c-var wje-child-pid)

*** - FFI:DEF-C-VAR: :TYPE option missing in (FFI:DEF-C-VAR WJE-CHILD-PID)
The following restarts are available:
ABORT          :R1      Abort main loop
Break 1 [2]> :r1
[3]> (ffi:def-c-var wje-child-pid :type ffi:int)

*** - Invalid option in (FFI:DEF-C-VAR WJE-CHILD-PID :TYPE FFI:INT): :TYPE
The following restarts are available:
ABORT          :R1      Abort main loop
Break 1 [4]> (quit)
home:~/lisp/experiments$

What did I do wrong here?

It's not totally obvious from the doc, but the :type option has to be nested inside its own list:

Code:

(ffi:def-c-var wje-child-pid (:type ffi:int))

That still won't work unless you link in some C code that defines that variable (maybe it should have been called ffi:declare-c-var).

Going back to the original problem, I don't understand why linux:waitpid doesn't work right either, I tried

Code:

(defun forking ()
  (let ((pid (linux:fork)))
    (if (= pid 0)
        ;; child
        (progn (sleep 1)
               (linux:exit 13))
        ;; parent
        (linux:waitpid pid 0))))
(format t "returned: ~A~%" (multiple-value-list (forking)))
(linux:perror "waitpid")

Code:

~/src/lisp$ clisp forking.lisp
returned: (-1 0)
waitpid: No child processes

Try the clisp mailing list perhaps?

wje_lq · 03-25-2011, 06:12 AM

Quote:

Originally Posted by ntubski

Try the clisp mailing list perhaps?

I actually did something a little more direct. I reported it as a bug at sourceforge, and they have fixed it for the next release. The fix is to advise me to use (posix:wait), and for the lisp developers to disable (linux:waitpid), since clisp ignores the SIGCLD signal unless the process is doing a (posix:wait). Unfortunately, that isn't a real fix; all it does is kick the can down the road. The fix doesn't work if the parent doesn't get around to doing the (posix:wait) until after the child has exited. So this code:

Code:

#!/usr/bin/clisp

(defun firstborn ()
   (format t "firstborn is sleeping 3 seconds~%")
   (sleep 3)
   (format t "firstborn is done~%")
   (quit 10))

(defun secondborn()
   (format t "secondborn is sleeping 3 seconds~%")
   (sleep 3)
   (format t "secondborn is done~%")
   (quit 11))

(setq fork-result (linux:fork))
(when (minusp fork-result)
   (format t "first (fork) failed~%")
   (quit 1))
(when (zerop fork-result)
   (firstborn))
(format t "results from first wait:~{ ~a~}~%"
   (multiple-value-list (posix:wait)))

(setq fork-result (linux:fork))
(when (minusp fork-result)
   (format t "second (fork) failed~%")
   (quit 1))
(when (zerop fork-result)
   (secondborn))
(format t "parent is sleeping 5 seconds~%")
(sleep 5)
(format t "parent is done sleeping~%")
(format t "(ignore-errors) returned:~{ ~a~}~%This is unfortunate.~%"
   (multiple-value-list (ignore-errors
      (format t "results from second wait:~{ ~a~}~%"
         (multiple-value-list (posix:wait))))))

produces this:

Code:

firstborn is sleeping 3 seconds
firstborn is done
results from first wait: 28627 EXITED 10
secondborn is sleeping 3 seconds
parent is sleeping 5 seconds
secondborn is done
parent is done sleeping
(ignore-errors) returned: NIL 
UNIX error 10 (ECHILD): No child processes

This is unfortunate.

So I guess I'm going to report another bug. Sigh.