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
