Re: Fast CGI fcgiapp questions

Mark Brown (
Mon, 01 Jul 1996 09:07:59 -0400

Message-Id: <>
To: Jim Fulton <>
Subject: Re: Fast CGI fcgiapp questions 
In-Reply-To: <> 
Date: Mon, 01 Jul 1996 09:07:59 -0400
From: Mark Brown <>

    I'm working on a Fast CGI module for the Python scripting language
    using the fcgiapp library.


    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

You are right.  fcgiapp does not exploit the full capabilities of
the protocol.

    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.

It would take quite a bit more work, and require changes to the API,
to allow concurrent FastCGI requests.  My current thinking is that the
best way to move fcgiapp forward is to port it onto the Tcl 7.5 I/O
framework, which provides a clean framework for non-blocking I/O.  The
Tcl 7.5 framework is lightweight (it does not pull in the Tcl
interpreter or anything like that), runs on Win95, WinNT, Mac, and
many Unixes, and is very well engineered.  The current fcgiapp.h
could be maintained for existing simple apps, and new non-blocking
capabilities exposed via new functions.