Re: difference between apache's mod_fcgi, mod_cgid, and mod_fcgid?

I've had to work through a similar (but different :) situation...  
don't know if this helps at all.

I have an fcgi app -- where I use FCGX_Accept() instead of FCGI_Accept 
().  Within the same thread I am also checking a postgres socket and  
an inotifyd fd using pselect.

My problem was that since FCG*_Accept is a blocking call on stdin my  
pselect loop was either missing signals - or not being able to  
respond in a timely fashion.

To fix it, i had to fcntl(FCGI_LISTENSOCKET_FILENO, F_SETFL,  
O_NONBLOCK), and then use a loop structure like:

while(1) {
     if ( ....CALL PSELECT.... returns a fd==FCGI_LISTENSOCKET_FILENO) {
           if ( FCGX_Accept_r(&request) ) {
              ... fastcgi stuff..
              FCGX_Finish_r(&request)
           }
     }
}

For some reason I had to call the Finish logic at the end of each  
cycle... but the end result is that I am able to run a server that  
can listen for/respond to input from apache, postgres, or file system  
changes.


Tom

On Dec 7, 2009, at 1:20 PM, Martin Chapman wrote:

> Rob,
>
> Let me get this straight.  You say you have one multi-threaded fastcgi
> instance running per Apache instance and you handle all requests  
> through
> that one instance using a thread pool of worker threads that all  
> block on
> FCGI_Accept() and asyncronously handle requests?
>
> I have used threads for years and attempted to do the same thing  
> but ran
> into the problem that fastcgi stores the handles to stdin and  
> stdout in a
> global non-syncronized structure.  Therefore, unless I put a mutex or
> critical section around the entire code in the accept loop, fastcgi  
> would
> reset the io pointers when another thread would call FCGI_Accept 
> ().  Thus,
> making it impossible to truly run more than one thread at a time.   
> The multi
> threaded example code that comes with FastCGI is completely flawed and
> tricks people who don't understand multi-threaded code into  
> believing that
> it actually works when in fact it does not.
>
> This is tricky to understand because you can make multiple threads  
> that all
> call FCGI_Accept(), and it will appear to work if you have a critical
> section or mutex around the code in your loop, BUT, because the  
> request
> handling code is all synchronized with the critical section or mutex
> (whatever you choose to synchronize with) it is really only letting  
> one
> block of code run at any given time.
>
> If you think I am mistaken then please tell me what you did to get  
> it to
> work because I would much rather run a single instance of my CGI  
> process
> with multiple threads than multiple single threaded CGI processes.
>
> Best regards,
> Martin
>
>
> -----Original Message-----
> From: fastcgi-developers-bounces 
> +chapmanm=pixia.com-xGejAJT2w6xVgU18Zptdi0EOCMrvLtNR@public.gmane.org
> [mailto:fastcgi-developers-bounces 
> +chapmanm=pixia.com-xGejAJT2w6xVgU18Zptdi0EOCMrvLtNR@public.gmane.org]
> On Behalf Of Rob Lemley
> Sent: Monday, December 07, 2009 12:04 PM
> Cc: FastCGI Developers
> Subject: Re: [FASTCGI] difference between apache's mod_fcgi,  
> mod_cgid, and
> mod_fcgid?
>
> Tom Bowden wrote:
>> Is the difference between these modules just a matter of version?  I
>> am using Apache 2.2+ server -- and it uses mod_fcgid... from what i
>> can tell the big difference is that the configuration keywords are
>> difference ( FcgidAuthenticator, FcgidAuthorizer, FcgidAccessChecker,
>> FcgidWrapper, etc.).
>
> mod_fcgid is a different project.  I've never used mod_fcgid.   It
> appears useful in situations where many processes are somehow started
> and you want the fcgid process manager to kill them when not needed.
>
> We have one multi-threaded FastCgiExternalServer process per apache2
> virtual host.  These servers never exit.  Therefore, I never saw the
> advantage to the mod_fcgid "process management strategy, which
> concentrates on reducing the number of fastcgi server, and kick out  
> the
> corrupt fastcgi server as soon as possible".
>
> I'm not sure, but I guess if you had a single threaded fcgi server and
> wanted to have the number of instances of it (processes) to grow and
> shrink dynamically, then maybe that's the purpose of mod_fcgid.  In  
> our
> case, we can accept fastcgi requests about as fast as apache sends  
> them,
> because our accept loop immediately spawns a new thread to handle the
> request and goes back to get the next request.
>
> One user has reported much slower response times for mod_fcgid.
>
> The fastcgi server library code is somewhat "scary", global variables,
> unclearly documented return codes, etc.  But it seems to work well for
> what we're doing.
>
> We've had problems with mod_fastcgi versions on windows.  I think we
> haven't been able to go above a certain version (2.8?) with the most
> recent version of apache 2.
>
> Rob
>
> _______________________________________________
> FastCGI-developers mailing list
> FastCGI-developers-xGejAJT2w6xVgU18Zptdi0EOCMrvLtNR@public.gmane.org
> http://mailman.pins.net/mailman/listinfo.cgi/fastcgi-developers
>
> _______________________________________________
> FastCGI-developers mailing list
> FastCGI-developers-xGejAJT2w6xVgU18Zptdi0EOCMrvLtNR@public.gmane.org
> http://mailman.pins.net/mailman/listinfo.cgi/fastcgi-developers