FYI: Both clang and GCC support both __sync and __atomic which support 64bit ints. We could add that functionality to APR...
> On Sep 17, 2018, at 8:57 AM, Jim Jagielski <j...@jagunet.com> wrote: > > In principle, I agree w/ making these counters atomic... up to now, some > minor discrepancies from "real" has been accepted noise, but the more > sophisticated we get, the less we can accept such potential drift. > > +1 to both. > >> On Sep 17, 2018, at 8:44 AM, Rainer Jung <rainer.j...@kippdata.de> wrote: >> >> I am thinking about making the proxy worker busy count atomic. Currently we >> use an apr_size_t in shared memory and increment/decrement simply using the >> C ++/-- operators. My (somewhat outdated) experience from mod_jk is, that >> this is not necessarily atomic and might lead to missing updates, letting >> the proxy worker busy count drift in any direction. >> >> Since I am also thinking about implementing a busy limit (per proxy worker), >> the correctness of the proxy worker busy count would get much more >> important. I think such a configurable limit would be really useful, because >> it allows some (limited) form of resource management in a reverse proxy, >> allowing to define the maximum number of concurrency that is allowed for >> each worker. This will prevent the reverse proxy from getting disfunctional >> when some slow worker backend starts to consume more and more reverse proxy >> slots. Not in all cases can you counter such a scenario with ambigous >> response timeouts, which will also kill sporadic slow requests. >> >> Note that apr atomics are 32 bit counters and current proxy worker busy >> counts might be 64 bit depending on platform. But real busy (concurrency) >> counters will hardly ever exceeed 32 bit limits. >> >> Any comments on >> >> - making proxy worker busy count atomic (using APR atomics) >> >> - adding a feature to restrict the maximum busyness per proxy worker >> >> Thanks and regards, >> >> Rainer >
