On Nov 22, 2013, at 2:22 PM, Jeff Trawick <traw...@gmail.com> wrote:
> On Sat, Nov 17, 2012 at 6:00 AM, Ruediger Pluem <rpl...@apache.org> wrote:
>
>
> j...@apache.org wrote:
> > + i = apr_atomic_dec32(&foo);
> > + if (i >= 0) {
>
> Why can we expect i < 0? apr_atomic_dec32 returns 0 if the dec causes foo to
> become zero and it returns non zero
> otherwise. Shouldn't this behavior the same across all platforms? And if not
> should that be fixed in APR?
>
> icc (Intel) builds of httpd 2.4.7 event MPM (with apr-1.5.0) bomb here.
>
> --enable-nonportable-atomics is specified for apr, though I haven't checked
> what that does with icc.
>
As noted back with the orig update, this test is due to the
fdqueue code in the new event:
apr_status_t ap_queue_info_set_idle(fd_queue_info_t * queue_info,
apr_pool_t * pool_to_recycle)
{
apr_status_t rv;
int prev_idlers;
ap_push_pool(queue_info, pool_to_recycle);
/* Atomically increment the count of idle workers */
/*
* TODO: The atomics expect unsigned whereas we're using signed.
* Need to double check that they work as expected or else
* rework how we determine blocked.
* UPDATE: Correct operation is performed during open_logs()
*/
prev_idlers = apr_atomic_inc32((apr_uint32_t *)&(queue_info->idlers));
/* If other threads are waiting on a worker, wake one up */
if (prev_idlers < 0) {
See the comments ("The atomics expect unsigned whereas...") for
the reason, etc.
When you say "icc (Intel) builds of httpd 2.4.7 event MPM (with apr-1.5.0) bomb
here."
do you mean that you get the 'atomics not working as expected' error
(and the internal server error) or that it core dumps?
