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