On Wed, Jul 19, 2017 at 12:44 PM, Luca Toscano <[email protected]> wrote: > Hi Yann, > > 2017-07-19 13:56 GMT+02:00 Yann Ylavic <[email protected]>: >> >> On Wed, Jul 19, 2017 at 1:45 PM, Jim Jagielski <[email protected]> wrote: >> > There's nothing in the way we handle UDS that prevents "reuse" >> > even understanding that we use the term "reuse" to mean both >> > "cache the IP address" and "use the connection as a one-shot". >> > There's no diff between UDS and sockets from the module PoV. >> >> +1 > > > +1 as well, this is my understanding too. > >> >> >> The comment in proxy_fcgi says: >> >> /* This scheme handler does not reuse connections by default, to >> * avoid tying up a fastcgi that isn't expecting to work on >> * parallel requests. But if the user went out of their way to >> * type the default value of disablereuse=off, we'll allow it. >> >> */ > > > This comment in the code was also a bit weird, what does it mean "a fastcgi > that isn't expecting to work on parallel requests" ? Even if reuse is off > multiple FCGI requests can land to the same FCGI backend at the same time > no? What does reuse=on do more other than forcing a worker to reuse the same > socket?
I think this comment is OK, but the related comment in the manual is bad. I think the original concern was some FastCGI that would not even accept() two connections. Keeping one idle in httpd process A would not allow another httpd process B to dispatch to the FastCGI because it is waiting on the first connection. But, this must be the case in only the most primitive hello-world of FastCGI's.
