apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jacob Lewallen <jlewa...@cs.ucr.edu>
Subject [PATCH] Problem with the queues
Date Fri, 21 Feb 2003 17:57:31 GMT
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 
 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

View raw message