apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ian Holsman <i...@apache.org>
Subject Re: [PATCH] Problem with the queues
Date Fri, 21 Feb 2003 19:48:58 GMT

Thanks for the patch.
I've been humbled twice now ;-)

I'll try to get to this tonight.

--Ian

Jacob Lewallen wrote:
> 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
>>
> 
> 
> ------------------------------------------------------------------------
> 
> ? apr_queue_overwrite_fix
> Index: apr_queue.c
> ===================================================================
> RCS file: /home/cvspublic/apr-util/misc/apr_queue.c,v
> retrieving revision 1.11
> diff -u -u -r1.11 apr_queue.c
> --- apr_queue.c	14 Feb 2003 04:39:07 -0000	1.11
> +++ apr_queue.c	21 Feb 2003 17:50:34 -0000
> @@ -333,7 +333,7 @@
>          }
>      } 
>  
> -    *data = &queue->data[queue->out];
> +    *data = queue->data[queue->out];
>      queue->nelts--;
>  
>      queue->out = (queue->out + 1) % queue->bounds;
> @@ -375,7 +375,7 @@
>          return APR_EAGAIN;
>      } 
>  
> -    *data = &queue->data[queue->out];
> +    *data = queue->data[queue->out];
>      queue->nelts--;
>  
>      queue->out = (queue->out + 1) % queue->bounds;



Mime
View raw message