Looping in APR as well... On Jan 27, 2011, at 1:43 PM, Jim Jagielski wrote:
> > On Jan 27, 2011, at 1:31 PM, Jim Jagielski wrote: > >> >> On Jan 27, 2011, at 12:21 PM, Jim Van Fleet wrote: >> >>> I noticed that ap_queue_pop removes elements from the queue LIFO rather >>> than FIFO. Also noticed that apr_queue_pop uses a different technique >>> which is not too expensive and is fifo, so I changed ap_queue/pop/push to >>> use that technique and the receive problems went away. >> Hmmm.... Not sure why the fdqueue would be LIFO. But certainly >> the above ain't right for pop! :) > > OK, looking over the history, it looks like the Q was changed from > FIFO to LIFO ~10years ago (worker)... The reasoning: > > This is a rather simple patch that may improve cache-hit performance > under some conditions by changing the queue of available worker threads > from FIFO to LIFO. It also adds a tiny reduction in the arithmetic that > happens in the critical section, which will definately help if you have > a lame compiler. > > Seems to me that changing back to FIFO would make sense, esp > with trunk. We can profile the expense of the '% queue->bounds' > but it seems to me that if it was really bad, we'd have seen it > in apr and changed it there... after all, all we're doing > with that is keeping it in bounds and a comparison and subtraction > would do that just as well... Doing some profiling, we can improve things more in apr_queue_pop/push... a++; if (a>=bounds) a -= bounds; is about 2-4 times as fast as: a = (a+1)%bounds; Seems like an EZ and obvious optimization to me ;)