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 [EMAIL PROTECTED]
