The reason, is that if we can add that to apr-1.7, we don't need to change the struct in httpd ;)
> On Sep 17, 2018, at 10:11 AM, Jim Jagielski <j...@jagunet.com> wrote: > > Well, we do check all this via configure... if the platforms supports 64 > "native" atomics then we could use those; if not, we could use the portable > versions as a backup (or simply return NOTIMPL). > > I don't see how this is different from how we handle atomics currently, but I > could be mistaken. > >> On Sep 17, 2018, at 10:03 AM, Nick Kew <n...@apache.org> wrote: >> >> Apologies to Jim. Sent this to him, meant for the dev list of course. >> >>>> On 17 Sep 2018, at 14:18, Jim Jagielski <j...@jagunet.com> wrote: >>>> >>>> FYI: Both clang and GCC support both __sync and __atomic which support >>>> 64bit ints. We could add that functionality to APR... >>> >>> We could indeed. >>> >>> But does that not potentially leave a nasty gotcha? Where a developer uses >>> it and expects >>> atomic operations, and their application is subsequently built on a >>> platform that >>> doesn't support those qualifiers. >>> >>> With the obvious fallback it breaks silently. With a more >>> sophisticated/heavyweight >>> fallback, we should consider whether it's maintainable or likely to fall >>> into disrepair. >>> >>> I wouldn't want to stop you, but it needs some thought. >>> >>> -- >>> Nick Kew >> >
