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 believe FastCGI does 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 speaking FastCGI'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
