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

Thanks for the info Tom but if it works we'll give you credit for this
thread anyway.  :)

Martin


-----Original Message-----
From: Tom Bowden [mailto:[email protected]] 
Sent: Monday, December 07, 2009 1:06 PM
To: Martin Chapman
Cc: 'Rob Lemley'; 'FastCGI Developers'
Subject: Re: [FASTCGI] difference between apache's mod_fcgi, mod_cgid, and
mod_fcgid?

I wish I could take credit for that particular gem -- but its  
something I read about online.  One error in the pseudo code below  
(btw) is that its

if ( FCGX_Accept_r(&request)==0) ) ....

not

if ( FCGX_Accept_r(&request))..


Tom

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

>
> Tom,
>
> That is awesome!  I was also using the FCGX_... commands to avoid
> fastcg_stdio.h from re-defining everything.  I am going to give  
> that a shot
> sometime in the next few days.  I'll write back when I get it  
> implemented
> and let you know how it went.  If it works then you are the man!
>
> Best regards,
> Martin
>
>
> -----Original Message-----
> From: Tom Bowden [mailto:[email protected]]
> Sent: Monday, December 07, 2009 12:36 PM
> To: Martin Chapman
> Cc: 'Rob Lemley'; 'FastCGI Developers'
> Subject: Re: [FASTCGI] 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
>