From: ahoward Date: 2003-03-09T18:40:35+09:00 Subject: Re: DRB and threads On Sun, 9 Mar 2003, Brian Candler wrote: > 'require fcgi.rb' pulls in the C version if you have it, otherwise it loads > the Ruby version. doesn't this always require 'fcgi.rb'? i mean, isn't only require 'fcgi' allowed to chose the *.so over the *.rb? > If there are going to be two versions then they really should be made as > similiar in behaviour as possible of course. The only reason I haven't > tested the Ruby version yet is that I've been too lazy to install stringio > :-) i don't know the history of this, but it certainly seems like a GC'd language would be a much better choice to write fastcgi servers in... > > > * the trapping of TERM and HUP doesn't work properly for me. What happens is > > > that if I send such a signal to the process, nothing happens (ps shows the > > > same pid) until the next HTTP request comes along, at which point it fails > > > and Apache returns '500 Internal Server Error'. The process is then > > > restarted and it's fine thereafter. i checked this out a little using strace - looks like accept (or calls before accept) are catching everything so there's not much to be done : [howardat@dhcppc1 fcgi-bin]# strace -p 10511 accept(0, 0xbfffe1ac, [112]) = ? ERESTARTSYS (To be restarted) --- SIGUSR2 (User defined signal 2) --- sigreturn() = ? (mask now []) accept(0, same goes for HUP, USR1, etc. > Yep, I tried both combinations. > > - with install_traps: I get the hanging behaviour as described above > > - with install_traps commented out: the process dies immediately on > receipt of TERM or HUP as expected (although if it were in the middle of > processing a request, it would bomb out without tidying up rather than > finish the request) i think sending SIGHUP and having one request fail is about a good as it gets ;-( i'm not sure what the alternative would be... > FYI I am currently working on adding FCGI server support to druby (there is > already a HTTP client in samples/http0.rb). Will let you know if I get it to > work! to what end? i mean, what would be the point of having a distributed fastcgi process? not that there isn't a point, i'm just wondering what you're on about? one thing which really needs addressed with fcgi is a way to run from a tty so you can enter params and see the html (or error messages) come blasting back out... not being able to do this is a real pain when debugging. -a -- ==================================== | Ara Howard | NOAA Forecast Systems Laboratory | Information and Technology Services | Data Systems Group | R/FST 325 Broadway | Boulder, CO 80305-3328 | Email: ahoward@fsl.noaa.gov | Phone: 303-497-7238 | Fax: 303-497-7259 ====================================