-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Yeah, that was me. :-P
FYI, the patch I submitted to the list is identical to the one you suggested. 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 > [EMAIL PROTECTED] - -- Paul Marquis [EMAIL PROTECTED] -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (FreeBSD) iD8DBQE+VoLfIuLAUo3z6B0RAkW5AKDEOHRZoEhEXp+GbVk23Rdz7eSZFgCbBL2n CvwuuB3MLphXhO1MTKFgJpc= =BNwk -----END PGP SIGNATURE-----
