On 29 Nov 2013, at 09:13, Kean Johnston wrote:

> Hello everyone, I am new to this list and I apologize in advance if this is 
> the wrong forum to ask module related questions or if this is a FAQ.

There is the modules-dev list.

> I am writing a module for FastCGI handling(*) that deals solely with FastCGI 
> applications over either a local socket or a TCP socket. It will be a 
> performance win if the connection between the module and the FastCGI 
> application is only created once, not per request. The FastCGI specification 
> supports this, as does php-fpm for example. What is the best way of doing 
> this?

I guess you're asking how to manage a resource that'll
outlive Requests and (client) Connections?

> It would be nice if this connection could be lazily established (i.e not 
> until it is needed) but if I have to use the child hook that wouldn't be a 
> train smash. Obviously in a multi-threaded MPM each thread needs its own 
> connection. I also have no experience with the event MPM so I don't know if 
> there are any gotchas associated with that.

Take a look at apr_reslist.  It may be even better than you'd hoped.
Indeed, your thought process looks not unlike
http://conferences.oreillynet.com/presentations/euos2006/kew_nick.pdf

> * Yes I am aware of other modules attempting to do the same.

Nothing wrong with reinventing the wheel if you have a vision of
a potentially-better wheel, but ...

> and mod_proxy_fcgi relies on the proxy framework, which has security 
> implications according to Apache's own docs, and it doesn't provide any AAA 
> capabilities.

Erm, what do you mean?

> It also supports the FastCGI "filter" role, which none of the others do 
> AFAICT.

You mean a fastcgi-based alternative to mod_ext_filter?  Sounds like
a worthwhile addition!

-- 
Nick Kew

Reply via email to