[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Chicken-users] Spiffy subprocess cleanup
From: |
Bryan Vicknair |
Subject: |
[Chicken-users] Spiffy subprocess cleanup |
Date: |
Wed, 22 May 2013 16:25:58 -0700 |
User-agent: |
Mutt/1.5.21 (2010-09-15) |
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
- [Chicken-users] Spiffy subprocess cleanup,
Bryan Vicknair <=