Hi Yann,

2017-07-17 13:49 GMT+02:00 Yann Ylavic <ylavic....@gmail.com>:

> On Sun, Jul 16, 2017 at 6:15 PM,  <elu...@apache.org> wrote:
> > Author: elukey
> > Date: Sun Jul 16 16:15:28 2017
> > New Revision: 1802077
> >
> > URL: http://svn.apache.org/viewvc?rev=1802077&view=rev
> > Log:
> > Propose backport of r1802040
> []
> >
> > +  *) mod_proxy_fcgi: Add the support for mod_proxy's flushpackets and
> flushwait params
> > +     trunk patch: http://svn.apache.org/r1802040
> > +     2.4.x patch: trunk works (modulo CHANGES)
> > +     +1: elukey
>
> Not introduced by your change, but about "flushwait" in general: any
> reason why a value of zero defaults to PROXY_FLUSH_WAIT (10ms)?
>
> I think it'd be interesting to let flushwait=0 be a real zero timeout
> (i.e. non-blocking poll() which,  on some systems, is likely a more
> efficient syscall than with the current minimal timeout of 1us).
>
> So how about:
> Index: modules/proxy/mod_proxy.c
> ===================================================================
> --- modules/proxy/mod_proxy.c    (revision 1802058)
> +++ modules/proxy/mod_proxy.c    (working copy)
> @@ -277,10 +277,7 @@ static const char *set_worker_param(apr_pool_t *p,
>          if (timeout > 1000000 || timeout < 0) {
>              return "flushwait must be <= 1s, or 0 for system default
> of 10 millseconds.";
>          }
> -        if (timeout == 0)
> -            worker->s->flush_wait = PROXY_FLUSH_WAIT;
> -        else
> -            worker->s->flush_wait = timeout;
> +        worker->s->flush_wait = timeout;
>      }
>      else if (!strcasecmp(key, "ping")) {
>          /* Ping/Pong timeout in given unit (default is second).
> ?
>
> PROXY_FLUSH_WAIT would still be the default when no "flushwait=" is
> used (both with flushpackets=on|auto, since this is what we initialize
> flush_wait with by default), but "flushwait=0" would work as
> expected/optimally IMHO.
>

Thanks for bringing this up, it looks strange to me too; +1 from my side.


> It seems that "flushwait=0" is not documented anyway, although the
> real question is: is it used with the current behaviour expected
> (which looks unlikely to me)?


I didn't get anything good out of the svn history/commits, but I'd say
definitely no (at least from the user/admin's point of view).

Luca

Reply via email to