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