Re: multi-threaded applications and fastcgi

Jim Fulton (jim.fulton@digicool.com)
Thu, 16 Jan 1997 09:27:02 -0500

Message-Id: <32DE3AB6.1427@digicool.com>
Date: Thu, 16 Jan 1997 09:27:02 -0500
From: Jim Fulton <jim.fulton@digicool.com>
To: Lok Man Norman Tam <lnt+@andrew.cmu.edu>
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

-- 
Jim Fulton         Digital Creations
jim@digicool.com   540.371.6909
## Python is my favorite language ##
##     http://www.python.org/     ##