Message-Id: <email@example.com> Date: Sun, 14 Sep 1997 17:59:32 -0400 To: Stanley Gambarin <firstname.lastname@example.org> From: Jonathan Roy <email@example.com> Subject: Re: mod_fastcgi In-Reply-To: <Pine.GSO.3.96.970914174403.20430C-100000@csa> Notice I said "after the suspend". ASSERT(sleepSeconds > 0); alarm(sleepSeconds); sigsuspend(&sigMask); alarm(0); is what I'm saying. If sigsuspend() returns from a signal other than the alarm, the alarm will still fire and have to be handled pointlessly. If the sigsuspend() returns because of the alarm, then the alarm(0) has no effect. The point is simply to avoid getting an alarm signal if sigsuspend has already exited due to a non-alarm signal. It isn't broken, and this doesn't "fix" anything, it's simply more "correct" I think... -Jonathan At 05:49 PM 9/14/97 -0400, Stanley Gambarin wrote: > > Unless I am misunderstanding something, the code as it >stands now is correct. After the process manager has performed a >first set of calculations, it knows when the next recalculation >needs to be done (sleepSeconds value). Now, if by that time, process >manager had received a SIGUSR2 or SIGTERM (which must be processed >immediately), it skips the call to sigsuspend. Otherwise, it >has nothing to do (so to speak) for at least sleepSeconds >interval, until either the interval expires, which means that >process manager needs to recalculate the values (and possible >restart fastcgi applications) or it receives SGIUSR2 or >SIGTERm signals. So, if i put alarm(0), then process manager will >not wake up when the timer expires but will only wake up when >the SIGUSR2 or SIGTERM is recieved, which is NOT a desired >situation. Therefore alarm(sleepSeconds) must be used, not >alarm(0). > > Stanley. > >On Wed, 10 Sep 1997, Jonathan Roy wrote: > >> >> >> Hey there, I noticed in your mod_fastcgi.c there is still: >> >> ASSERT(sleepSeconds > 0); >> alarm(sleepSeconds); >> sigsuspend(&sigMask); >> } >> >> there should be an alarm(0) after the suspend. Thought that was in one of >> the patches we provided for mod_fastcgi.c, but maybe not. (Actually, our >> patches were for the 1.x version, so maybe they didn't make it into the 2.x >> base David was applying fixes to.) >> >> -Jonathan >> >> At 12:26 AM 9/8/97 -0400, Stanley Gambarin wrote: >> > i got the changes by David MacKenzie together witha simple >> >Makefile and installation script and put it on >> >http://www.cs.bu.edu/staff/TA/stanleyg/apache/index.html >> >I compiled it on Linux with 1.2.4. and 1.3 version of Apache. >> >(if you are compiling with 1.2.4., change all occurrences of >> >ap_md5 to md5, as there is a conflict in function naming). >> >There are no code changes, but I put a lot of TODO stuff, so if >> >poeple are interested...in any case, i will be updating the module >> >weekly, so stay tuned. >> > stanley. >> > >> > >> >> -- >> Jonathan Roy - firstname.lastname@example.org - Idle Communications, Inc. >> Idle Communications, Inc. accepts contract programming >> work for general purpose tools (or CGI) in Perl/C/C++. >> >> > > -- Jonathan Roy - email@example.com - Idle Communications, Inc. Idle Communications, Inc. accepts contract programming work for general purpose tools (or CGI) in Perl/C/C++.