apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ian Holsman" <li...@holsman.net>
Subject Re: [PATCH] Problem with the queues
Date Sat, 22 Feb 2003 17:08:38 GMT
Thank you Paul & Jacob.
the patch has been comitted.

in the future, if your patch has been 'ignored' just 
post it again in a week. 
people on the list sometimes assume that someone else will do it,
and it falls through the cracks.


I'm interested in what your both using APR, and the queue code for. 

On Fri, 21 Feb 2003 09:57:31 -0800, Jacob Lewallen wrote:

> Some more problems with apr_queue. . .
> Erwin De Wolff wrote:
>>My application uses queues and I notice that I had some difficulties when
>>reaching the end and start of the queue. I'm using the latest (21 febr
>>2003) snapshot of apr and apr-util. Platforms on which it occurs, Windows
>>and Linux. To make the problem more accessible I use most of the same
>>code as the testqueue.c provided in the distribution. Only to simplify I
>>use one producer and one consumer only and a queue of size 1. The
>>producer pushes values 0,1,2,3,... and the consumer pops them one by one.
>>The following output is obtained:
>>	0: value 0 succesfully pushed.
>>	1: value 1 succesfully pushed.
>>	        0: value 1 succesfully popped.
>>	2: value 2 succesfully pushed.
>>      	  1: value 2 succesfully popped.
>>	3: value 3 succesfully pushed.
>>      	  2: value 3 succesfully popped.
>>	        3: value 3 succesfully popped.
>>You can notice a few things:
>>1. value 0 is never popped
>>2. there are two values pushed on a queue of size 1! 3. value 3 is popped
>>twice on a queue of size 1.
>>I don't think I made a mistake in the code, but just for those who might
>>doubt that, I attached the used code.
> [code removed]
> Here's what's going on here. With a queue size of 1, there's only one
> position in the queue for placing data. In apr_queue_pop, we return the
> address of the popped item "in the queue's own array" (hence us having to
> dereference twice to get our integer pointer above). So here's how things
> breakdown:
>  P: we push 0, its placed in data[0]
>  P: we try to push 1, its blocked, because we're full C: we pop, and are
>  returned the address of data[0] (in our case, a
> pointer to where the pointer to 0 is zero)
>  P: unblock, push 1 into the queue (overwriting data[0] with the new
> pointer)
>  C: we dereference the pointer to data[0] that was returned, which has
> since been replaced with a pointer to 1.
> And this goes on. I think that this is responsible for all of the behavior
> we see above. I'm almost positive that I've seen someone complain about
> how the apr_queue code returns the address of the item, rather than the
> value itself. This is what the attached patch does, if anybody has any
> reason for keeping the existing behavior, I'd love to hear them. This, of
> course, breaks any code that uses apr_queue_pop, so it's a big deal.
> jacob lewallen
> jlewalle@cs.ucr.edu

View raw message