Re: [Chicken-users] Spiffy subprocess cleanup

2013-05-23 Thread Peter Bex
On Wed, May 22, 2013 at 10:29:03PM -0700, Evan Hanson wrote: After looking at a bit more, here's what I believe is *actually* happening: The invalid call to process* is signaling an exception in the child, which is handled internally by spiffy (spiffy.scm:470), causing that process to loop

Re: [Chicken-users] Spiffy subprocess cleanup

2013-05-23 Thread Bryan Vicknair
On Thu, May 23, 2013 at 09:14:25AM +0200, Peter Bex wrote: On Wed, May 22, 2013 at 10:29:03PM -0700, Evan Hanson wrote: After looking at a bit more, here's what I believe is *actually* happening: The invalid call to process* is signaling an exception in the child, which is handled

Re: [Chicken-users] Spiffy subprocess cleanup

2013-05-23 Thread Peter Bex
On Thu, May 23, 2013 at 08:57:09AM -0700, Bryan Vicknair wrote: Thanks a lot Evan and Peter. That was very helpful. I started looking at the process-fork source to write a patch, but I'm not familiar enough with chicken-core yet to tackle it. For now I changed my code to use the process*

[Chicken-users] Spiffy subprocess cleanup

2013-05-22 Thread 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

Re: [Chicken-users] Spiffy subprocess cleanup

2013-05-22 Thread Evan Hanson
Hi Bryan, I tried to paste a response but missed you in #chicken. I think you need to make sure to close the ports returned by process* (in your paste, the close-input/output-port forms aren't running since process* is signaling an error):

Re: [Chicken-users] Spiffy subprocess cleanup

2013-05-22 Thread Evan Hanson
After looking at a bit more, here's what I believe is *actually* happening: The invalid call to process* is signaling an exception in the child, which is handled internally by spiffy (spiffy.scm:470), causing that process to loop back to the start of the accept-next-connection procedure inside