Ian Holsman wrote:
On Sun, 09 Feb 2003 13:28:13 -0800, Jacob Lewallen wrote:
Hi there, I've stumbled on a bug in the apr_queue_t code... When
calling apr_queue_pop to retrieve an item from the queue the call may
block indefinately despite items having been pushed in. Same things goes
for calls to apr_queue_push that are blocking until there is room in the
queue (they may stay blocked even though items have been popped from the
queue). The problem lies in the logic that manages the two conditions that
help operate the queue - NOT_EMPTY, and NOT_FULL. In apr_queue_push, the
NOT_EMPTY condition is only signaled if the queue was empty prior to
adding the new item. This can cause problems if there are multiple threads
blocked in calls to apr_queue_pop and then two or more successive calls to
apr_queue_push are handled prior to one of the apr_queue_pop awakening...
for example:
another approach would be just to send signals every time a pop/push
occurs, or to have the pop/push wake every waiting thread and try to get
them to re-lock it.
Yes, this would absolutely work and was something I did in narrowing
down the problem. My intention in the patch was to keep the spirit of
the original implementation and only signal when necessary, since that
seemed to be a good idea. The solution is really unimportant to me, but
I make heavy use of apr_queue in some software of mine so a working
apr_queue is my priority. Thanks,
--
jacob lewallen
[EMAIL PROTECTED]
