Re: [PATCH] Problem with the queues - commited

[Ian Holsman <li...@holsman.net>]

Thanks guys.
this code has been committed. 


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