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/ ##