Re: mod_fastcgi 2.0 beta 1
Sven Verdoolaege (skimo@breughel.ufsia.ac.be)
Thu, 8 May 1997 19:48:16 +0200
Message-Id: <19970508194816.NV23075@breughel.ufsia.ac.be>
Date: Thu, 8 May 1997 19:48:16 +0200
From: skimo@breughel.ufsia.ac.be (Sven Verdoolaege)
To: fastcgi-developers@OpenMarket.com
Subject: Re: mod_fastcgi 2.0 beta 1
In-Reply-To: <199705011546.LAA07410@quip.eecs.umich.edu>; from Ken Alexander on May 1, 1997 11:46:44 -0400
On May 1, kalex@eecs.umich.edu (Ken Alexander) wrote:
> This is in regards to the perl5.003 / sfio / solaris 2.5
> multiple-fcgi-process hanging death problem.
>
> Gambarin writes:
> > 2. In my very limited testing of the dynamic applications, I came across
> > a possible bug, where the two almost silmultaneous accesses were made to
> > the same fastcgi application. The application code was of the form
> > print("text/html\r\n");
> > sleep(10);
> > print("Hello world");
> > The version of the above program written in C ran fine, spawning off 2
> > copies of the application and servicing them. However, the same program
> > written in Perl (Perl 5.003_26 with Sfio 0.28 under Solaris 2.5) resulting
> > in hanging the server and never returning the request. Furthermore, any
> > subsequent requests to any other fastcgi application did not go through.
> > I am assumming that there might be some race condition in Perl's accept()
> > loop, however I don't have to time to delve into it (see below).
>
>
> Guess what - it isn't just in dynamic applications.
> I have this same problem with regular "AppClass" applications under
> perl5.003_95 / sfio0.28 / solaris2.5.1. Multiple apps die and client hangs.
> This makes it quite unusable (which is why I had to go back to perl5.002
> and instead found the bug in Configure that caused signals to be broken).
>
I can't reproduce this on perl5.003_99 / sfio97 / linux 2.1.3[56] .
I wasn't able to try the dynamic variant; I get a failed assertion
on line 3698
/* find next free slot */
for(i=0;i<maxClassProcs;i++) {
if((s->procInfo[i].pid == -1) &&
((s->procInfo[i].state == STATE_READY) ||
(s->procInfo[i].state == STATE_KILLED)))
break;
}
ASSERT(i<maxClassProcs);
s->procInfo[i].pid = -1;
s->procInfo[i].state =
STATE_NEEDS_STARTING;
break;
skimo