[Chicken-users] Spiffy subprocess cleanup

[Bryan Vicknair]

I have a web app using spiffy that uses (process*) in one of the views to wait
on a script to do some work.  I was accidentally passing in a non-existent
script name to process*, which was causing a 500 code to be returned by
spiffy. 

The problem is that there is no indication of any error sent to stderr/stdout
by spiffy.  Also, each time I visit the broken view's URL, a new subprocess is
created and never killed.

Here is an example:

  (use posix spiffy)
  
  (define (fail)
    (define-values (i o pid e) (process* "non-existant" '("arg1" "arg2")))
    (close-output-port o)
    (close-input-port i)
    (close-input-port e))
  
  
  (define (server arg)
    (print "starting subprocess...")
    (fail)
    (send-status ok "done"))
  
  (access-log (current-output-port))
  (error-log (current-error-port))
  (debug-log (current-output-port))
  (handle-not-found server)
  (root-path "./")
  (start-server)



If you save the above code in foo.scm, compile and run it, then go to
http://localhost:8080/bla a few times so the handle-not-found handler is
called, you'll get a 500 error.  But the shell you started foo in won't show
any details on the error.  If you look at pstree, you'll see that there are
subprocesses hanging around: sh--bash--foo-foo-foo-foo

I thought there might be strange interplay between the thread that spiffy is
using to serve the view and the (process*) call.  The example below doesn't
involve spiffy, it just starts a thread that will fail by calling (process*)
with a non-existent script name:

  (use srfi-18 posix)


  (define (fail)
    (define-values (i o pid e) (process* "non-existant" '("arg1" "arg2")))
    (close-output-port o)
    (close-input-port i)
    (close-input-port e))


  (print "staring thread that will fail")
  (thread-start! (make-thread (lambda()
                                (thread-sleep! 1)
                                (fail))))

  (thread-sleep! 2)
  (print "main thread done")

This works as expected however.  There are no subprocesses lying around, and
the error appears on stderr.

Does anyone understand why the (process*) call in the spiffy example doesn't
show an error on stderr/stdout and leaves subprocesses alive?


Bryan