apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Marquis <pmarq...@pobox.com>
Subject Re: [PATCH] Problem with the queues
Date Fri, 21 Feb 2003 19:49:37 GMT
Hash: SHA1

Yeah, that was me.  :-P

FYI, the patch I submitted to the list is identical to the one you 

On Friday 21 February 2003 12:57 pm, Jacob Lewallen wrote:
> 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

- -- 
Paul Marquis
Version: GnuPG v1.2.1 (FreeBSD)


View raw message