Re: Using select() with FASTCGI

Mark Brown (mbrown@OpenMarket.com)
Thu, 23 May 1996 11:40:02 -0400

Message-Id: <199605231540.LAA09145@breckenridge.openmarket.com>
To: Paul Mahoney <ptm@xact.demon.co.uk>
Subject: Re: Using select() with FASTCGI 
In-Reply-To: Your message of "Wed, 22 May 1996 19:57:21."
             <Pine.SCO.3.90.960522193854.20801H@xact4.xact.com> 
Date: Thu, 23 May 1996 11:40:02 -0400
From: Mark Brown <mbrown@OpenMarket.com>


    I need to wait on a couple of streams and process each as some
    input arrives. One stream the FCGI_stdin and the other is a pipe
    from a child process. So I thought I'd use the select() call.

    ...

    As I write this I realise the FCGI_ routines can't support what I
    want to do :-(  ...

The fcgiapp library that exists today is not designed to support your
requirement.  (fcgi_stdio is layered on fcgiapp, so it doesn't
help you, either.)

Programming in the event-driven style using select() isn't a very
comfortable fit with the stream-oriented style that fcgiapp
implements.  An event-driven application has to be aware of how many
bytes are available in the input buffer and must never attempt to read
more than are available; it would be an application programming
error to do so.  (I'm curious about your application; most
Web applications don't do a lot of reading from stdin, so
it works OK to read stdin to EOF before doing anything else.)

If you accept this constraint then you could (a) expose the connection
socket so that you could use it with select() and (b) expose a
function to be called when select() indicates that data is available
for reading from the socket.  If this work was done correctly it could
be folded back into the shared code base.  If you are interested in
pursuing this approach I could give you more advice offline.

My own idea for supporting concurrency within FastCGI applications is
to exploit POSIX (and NT) threads.  This approach fits very well with
streams and requires only minor surgery to the fcgiapp library.  It
will allow us to support multiple connections and multiplexed
connections as well as handling your type of requirement.  If you or
others are interested in this topic, I would be glad to share some
design sketches and get some feedback on them.

    --mark