Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Received-SPF: pass (nike.apache.org: local policy)
From: Jim Jagielski <jim@jaguNET.com>
Message-Id: <200708062355.l76NtPcf041541@devsys.jaguNET.com>
Subject: Re: svn commit: r563147 -
 /httpd/httpd/trunk/server/mpm/experimental/event/fdqueue.c
To: dev@httpd.apache.org
Date: Mon, 6 Aug 2007 19:55:25 -0400 (EDT)
Reply-To: jim@jaguNET.com
In-Reply-To: <46B7813E.5010709@apache.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Ruediger Pluem wrote:
> 
> 
> 
> On 08/06/2007 04:20 PM, jim@apache.org wrote:
> > Author: jim
> > Date: Mon Aug  6 07:20:24 2007
> > New Revision: 563147
> > 
> > URL: http://svn.apache.org/viewvc?view=rev&rev=563147
> > Log:
> > These atomics expect apr_uint32_t *... The expectation, of course,
> > is that the add/inc still works "as expected" even though we
> > are using signed values.
> 
> Hm. I have a bad feeling here. These atomics are platform specific and seemed
> to be designed for unsigned ints. Are we really sure that they can handle signed ints
> as well? Comments from an atomics guru from APR?
> 

As mentioned in the log, the patch isn't designed to "fix" the
fact that we're using a signed 32 bit int with a function (assembly
no less!) that expects unsigned. Rather it's to remove a compiler
error which complains about it. Ideally, we should craft a different
method than idler going negative to reflect the state change, and I
have an idea about that. 

-- 
===========================================================================
   Jim Jagielski   [|]   jim@jaguNET.com   [|]   http://www.jaguNET.com/
	    "If you can dodge a wrench, you can dodge a ball."