On Thu, Nov 23, 2023 at 4:46 PM Yann Ylavic <ylavic....@gmail.com> wrote: > > On Thu, Nov 23, 2023 at 4:17 PM Ruediger Pluem <rpl...@apache.org> wrote: > > > > On 11/23/23 3:53 PM, Yann Ylavic wrote: > > > > > > As for the 64bit atomics vs APR version dance, it's because the former > > > are not available before apr-1.7 and likely not reliable before 1.7.4 > > > (at least for some architectures where builtins are not available). In > > > any case we need a fallback for apr < 1.7, but maybe to keep this > > > simpler we should fall back to non-atomics (as before) in this case. > > > It all looks over complicated for the feature, but I can't think of > > > something simpler and still correct.. > > > > Understood. > > > > I am asking because I guess I am hit now by races in the byrequests LB > > with the worker->s->lbstatus. > > I probably want to look for a way to solve this in a more generic way > > for various shared worker fields. > > lbstatus is an int so the 32bit apr_atomic API could do I think.
I mean, if lbstatus becomes inconsistent because of the race then we can do something, but if it is e.g. that a worker switches from error state to non-error become some threads can connect while some others can't this is something we should address elsewhere (like a failure threshold). > Maybe we need some ap_atomic_{int,long,size_t,..}_*() helpers for > system dependent widths. It preferably would be implemented in APR but > in the meantime we could have something in httpd already. > What we should avoid IMO is needing 64bit atomics on 32bit systems > (because we'd have to reimplement the mutexes etc), but apart from > that I think we can wrap anything using the existing apr atomics. What we need for lbstatus is ap_atomic_int_or() and ap_atomic_int_and_not() it seems, both could be implemented with a cas32 loop. > > Regards; > Yann.