Re: Fast CGI fcgiapp questions

Jim Fulton (jim.fulton@digicool.com)
Mon, 01 Jul 1996 10:01:44 -0400

Message-Id: <31D7DA48.3398@digicool.com>
Date: Mon, 01 Jul 1996 10:01:44 -0400
From: Jim Fulton <jim.fulton@digicool.com>
To: Mark Brown <mbrown@openmarket.com>
Subject: Re: Fast CGI fcgiapp questions 

Mark Brown wrote:
> 
>     I'm working on a Fast CGI module for the Python scripting language
>     using the fcgiapp library.
> 
> Great!
> 
>     I've been able to get it working OK, but I have a couple of questions:
> 
>     1. It is my understanding that the Fast CGI protocol supports
>        threaded applications, because packets for multiple requests
>        can be interleaved.  ... FCGX_Accept "Finishes the request
>        accepted by (and frees any storage allocated by) the previous
>        call to FCGX_Accept."  Am I reading this right?  This seems
>        like a serious limitation, given the capabilities of the
>        protocol.
> 
> You are right.  fcgiapp does not exploit the full capabilities of
> the protocol.

Are there any libraries that do?

Here is a related motivating question.  Fast CGI apps read and write 
file streams.  Are these streams plumbed through to the browsers? 
(This would be advantageous for some apps, as the browser could 
display partial results while computation proceeds.) Or
do web servers buffer the stream behavior away?  Can a slow browser
(or connection with same) cause a single-threaded Fast CGI application
to block?  Or is all input gathered from the browser by the server before
sending the request to the app and all output from the app gathered
by the server before sending to the browser?

> 
>     2. There doesn't seem to be any way to call FCGX_Accept in a
>        non-blocking manner or to test for a request without blocking.
>        I would like to be able to test for other events within my
>        "accept" loop, or check for Fast CGI events in, say, an
>        CORBA/ILU ORB main loop.
> 
>        I suppose I could add a call that does a select call on
>        reqDataPtr->socket in fcgiapp.c.  Is there any reason not to do
>        this?  Are there any plans to provide a similar interface in
>        the future? Or am I simply missing something.
> 
> You should be able use fcntl to put the listening socket
> (FCGI_LISTENSOCK_FILENO, not reqDataPtr->socket) into non-blocking
> mode.  Then your event loop can select on the listening socket as well
> as other events.  If the listening socket shows itself ready for read,
> then call FCGX_Accept.  Naturally you'd use FCGX_Finish at the end of
> the request.
> 
> You can do this without API or library changes.  I haven't tried it
> but it sure seems like it should work.  Your application might still
> block when doing I/O to reqDataPtr->socket, but this is pretty
> unlikely to happen given the buffer sizes.

The API does not export reqDataPtr, so an API change would be necessary.

> 
> It would take quite a bit more work, and require changes to the API,
> to allow concurrent FastCGI requests. 

The change to the API would be minor.  All you would need is a routine
like FCGX_Accept that doesn't implicitly finish previous requests.  I can
imagine that the implementation would be a bit more complex, which is
why I was hoping that Open Market would do it. :-)

Jim

-- 
Jim Fulton         Digital Creations
jim@digicool.com   540.371.6909