Re: multi-threaded applications and fastcgi

Jim Fulton (
Thu, 16 Jan 1997 09:27:02 -0500

Message-Id: <>
Date: Thu, 16 Jan 1997 09:27:02 -0500
From: Jim Fulton <>
To: Lok Man Norman Tam <>
Subject: Re: multi-threaded applications and fastcgi

Lok Man Norman Tam wrote:
> Excerpts from mail: 15-Jan-97 Re: multi-threaded applicat.. Stanley
> Gambarin@OpenMar (629*)
> >       As of today, we have not yet implemented any multi-threaded
> > code for FastCGI.  The idea was considered, but was delayed due to
> > other more pressing issues.
> So is it under developement now? or the plan is cancelled?

Mark Brown put a first cut together this summer which we were 
supposed to test. Unfortunately, we sort of dropped the ball 
and didn't get back to him with problems until much later. :-(  
When I did get back to him (I couldn't get it to work and found 
several bugs) he could no longer spend time on it.  There is a 
start, and I suspect it wouldn't take all that much effort to 
get it working.

> I think being multi-threaded is very important for more people
> to use FastCGI.

I agree.  This is especially true given the way that the current
Fast CGI implementation does (or actually, the way it doesn't do) 
buffering with the browser.  I can essentially lock up a Fast CGI
application by simply telneting to an HTTP server, starting a POST 
to a Fast CGI URL and not typing anything.  This is a serious
security problem and a serious problem when clients have slow
connections. One can get around this to some degree by running 
multiple processes, but that introduces other problems.  Multi-
thread support would provide a way for applications to address 
this problem. We have been avoiding Fast CGI due to this
(and due to lack of Windows support).


Jim Fulton         Digital Creations   540.371.6909
## Python is my favorite language ##
##     ##