Re: multi-threaded applications and fastcgi

Mark Brown (mbrown@OpenMarket.com)
Tue, 23 Jul 1996 21:39:52 -0400

Message-Id: <199607240139.VAA14851@breckenridge.openmarket.com>
To: fastcgi-developers@OpenMarket.com
Subject: Re: multi-threaded applications and fastcgi
In-Reply-To: <199607101808.OAA02824@loon.odi.com> 
Date: Tue, 23 Jul 1996 21:39:52 -0400
From: Mark Brown <mbrown@OpenMarket.com>


George Feinberg asked,

    Anyone from OpenMarket out there?  I would very much like to
    support FastCGI without hacking your source code to make it
    thread-safe, and hooking into it below the level of the currently
    exposed API.

We've been unresponsive because Bill Snapper and I took vacation at
the same time.  Back now.

Just before going on vacation I designed and coded up a prototype
multi-threaded library based on POSIX threads.  It has compiled on
Solaris 2.5 but has gotten no testing as yet.  I'm happy to give this
code to anybody who is capable of working with multi-threaded code
that's probably broken.  I.e. if you're willing to debug this code for
me, please send me mail, I won't stand in your way!  (The benefit to
you of this special limited-time offer is that you get the first shot
at giving feedback on the design, and suggesting changes.)  Otherwise
you can have the code when it has gotten some testing here.  I can't
offer a firm date because of other responsibilities here.

During my time off I laid out the changes that will be needed to
fcgiapp.c in order to support select-based concurrency, specifically
using the Tcl 7.5 I/O channel interface.  (Don't worry -- these
changes, when they happen, will not be visible to existing fcgiapp
applications, and fcgiapp applications won't include the Tcl 7.5 I/O
libraries.)  The bonus of imposing this structure is that by doing so
we completely separate the FastCGI protocol processing code from the
fcgiapp streams code.  This gives us a new module that only does
procotol processing.  This module will be usable in different language
environments that use different stream abstractions.  For instance,
with this module in hand it should be a snap for someone to plug
FastCGI into C++ streams, Python streams, whatever.

    (It would also be nice if the documentation were correct with
    respect to multi-threaded programs.  At best, it's misleading).

We've always tried to keep a clear distinction between the
capabilities allowed by the FastCGI specification and the capabilities
of particular pieces of code that conform to the FastCGI
specification.

The current app libs are all single-threaded, but we tried to be
careful not to preclude multi-threaded implementations.  We think that
supporting both styles is pretty important.  Requiring everyone to
write thread-safe code (as ISAPI and now NSAPI do) would be as bad as
not allowing multi-threaded applications.

We gladly accept help in debugging our documentation.  Please point to
particular words in the documentation and suggest how to change them.

    --mark