No, not yet, I'm using Lighttpd and it doesn't use all of the FCGI protocol so some things aren't implemented and others just not tested. I'll try to clean it up a little and put in some comments with regards to what might need fixing, hopefully I can get that done this week.
/Patrik On Tue, Jan 6, 2009 at 7:41 AM, Ramana <[email protected]> wrote: > > Patrik is your FastCGI library available, even without the ability to > flush output to the web server? > > I think I'd be interested in using it at some point (just for some > games/toy applications). I came across this post while looking at the > possibility of writing such a library myself, and I'm glad someone > else had the idea first =) > > On Jan 4, 8:12 am, "Patrik Husfloen" <[email protected]> wrote: >> On Sat, Jan 3, 2009 at 4:40 AM, Derick Eddington >> >> >> >> <[email protected]> wrote: >> >> > On Fri, 2009-01-02 at 17:48 -0800, Derick Eddington wrote: >> >> On Fri, 2009-01-02 at 18:31 -0500, Abdulaziz Ghuloum wrote: >> >> >> > On Jan 2, 2009, at 9:32 AM, Patrik Husfloen wrote: >> >> >> > > I've been working on a Fast CGI [1] library for Ikarus (and other R6 >> >> > > compliant schemes?) >> >> >> > > I'm currently using make-custom-binary-output-port to create ports for >> >> > > stdout and stderr and because I want to support multiplexed >> >> > > connections over the fcgi connection >> >> >> > Custom ports would not give you a way to do IO multiplexing. >> >> > In Ikarus, you can use the nonblocking sockets for that, but >> >> > you'd be writing ikarus-specific code then. >> >> >> I believeFastCGIdoes its own multiplexing over one connection to a >> >> persistent CGI process (the ikarus process) that continuously services >> >> multiple requests simultaneously and that Patrik is trying to make >> >> custom ports that read/write the one connection speakingFastCGI's >> >> multiplexing protocol so each logical request and response stream can be >> >> dealt with as a port. If the underlying one connection was an Ikarus >> >> nonblocking port then wouldn't the custom ports on top work >> >> automatically as nonblocking (because of the automatic continuation >> >> capture and rescheduling)? >> >> > Well, thinking about it more, it wouldn't work for the custom input >> > ports to read from the underlying one connection. Only one loop would >> > read from it and put the incoming messages in the appropriate custom >> > input port's inbox that's somehow wired so port-reading uses this inbox, >> > somehow nonblocking. Or something. >> >> Yeah, but it doesn't have to work for reading, all input data is >> collected before the request is dispatched. There's a custom input >> port layered on top of a list of bytevectors that's passed to the >> request handler as "stdin". >> >> > -- >> > : Derick >> > ---------------------------------------------------------------- >> >> /Patrik
