+1
On Dec 4, 2013, at 11:19 AM, Daniel Lescohier wrote:
> So it sounds like I should go ahead and work on an implementation of the time
> caching using apr_atomic_cas32 and apr_atomic_dec32. This won't be an issue
> for RHEL/CentOS/etc., because they're using old versions of httpd. We can
>
So it sounds like I should go ahead and work on an implementation of the
time caching using apr_atomic_cas32 and apr_atomic_dec32. This won't be an
issue for RHEL/CentOS/etc., because they're using old versions of httpd.
We can put something in the release notes saying that for 32-bit i486,
i586,
On Wed, Dec 4, 2013 at 7:47 AM, Jim Jagielski wrote:
> Also, IMO, the default should be non-portable
> atomics.
>
Yes: that is the purpose of APR: having a portable API on top of
non-portable implementations for each platform.
Adding APR dev list:
IMO, httpd should expect APR to "do the right thing". If APR
isn't doing that, then it's an APR bug and needs to be fixed/
addressed within APR.
All this implies that the atomics code in APR needs a serious
review and update.
We should also look into leveraging what we can f
So I think we should reach a consensus on what approach to take. My goal
was to implement an algorithm that is correct, with code that is easy to
maintain. I think using the apr_atomics functions meets those goals the
best. The downside are for those systems that are running 32-bit i486,
i586, i
(continued, hit send too early)
%ix86 i386 i486 i586 i686 pentium3 pentium4 athlon geode
However, I looked at the CentOS 6 apr.spec, and it's not overriding the
default.
I took a look at apr's configure.in, and it's default for all architectures
except for i486, i586, and i686 is to use the real atomic ops, but for
those three architectures the default is to use the "generic" atomic ops.
Any idea why there is a special rule for those three architectures?
There's no
On Dec 3, 2013, at 12:01 PM, Daniel Lescohier wrote:
> If the developers list is OK using apr_atomic in the server core, there would
> be lots of advantages over trylock:
All of APR is available for use in server core ;)
I personnally like this solution better (IMHO) since it does not rely on
apr_thread_mutex_trylock() to be wait-free/userspace (eg. natively
implements the "compare and swap").
On the other hand, apr_atomic_cas32() may itself be implemented using
apr_thread_mutex_lock() when USE_ATOMICS_GENERIC is
If the developers list is OK using apr_atomic in the server core, there
would be lots of advantages over trylock:
1. No need for child init.
2. No need for function pointers.
3. Could have a lock per cache element (I deemed it too expensive
memory-wise to have a large mutex structure p
I infer that you think that in this particular case, the function macro
makes the code more readable and maintainable. I don't think one can
define an absolute rule, it's a judgment call whether a macro increases or
decreases clarity and maintainability. It reminds me of 'goto': most of
the time,
On Tue, Dec 3, 2013 at 12:13 AM, Daniel Lescohier <
daniel.lescoh...@cbsinteractive.com> wrote:
> The current time caching implementation in util_time.c and
> mod_log_config.c is not guaranteed to work with all compilers and cpu
> architectures. I have some proposed code I've written, that I want
At first blush, the below looks very workable! On a slightly
off-topic topic, however, I wonder if macros are the way to
go. Long long ago function calls were really really expensive.
Does the decreased clarity (and debugging capability) really
offset the saved cycles? Agreed that it's not fully a
The current time caching implementation in util_time.c and mod_log_config.c
is not guaranteed to work with all compilers and cpu architectures. I have
some proposed code I've written, that I want to get input from the mailing
list on, before continuing on to compile and test it.
The old implement
14 matches
Mail list logo
