At 10:40 AM 7/31/02 +0200, Andreas Bourges wrote: >On Wednesday 31 July 2002 10:25, Elizabeth Mattijsen wrote: > > Are you sure that other threads are taking values off of the queue? And > > that the memory growth is not just caused by the growing of the queue by > > itself? >yes, we're processing the objects from the ->dequeue method and it works >quite >well. I also have implemented some debugging code, which uses ->pending. It >shows the Queue-size varies between 0 and 100 entries (while processing about >50 objects per second).
Ok, so we've ruled out that problem then... >But I faced another problem lately. It seems that the task of enqueuing >objects takes too long for our application. Imagine a deamon, taking packets >from the interface and enqueues them. We get approx. 50 packets/second. When >using the Queue, we loose about 30% of the packets. Seems to me, that they >are lost, while the ->enqueue method is called. Do you have any experience >concerning the speed of the enqueue method? It could also be an operating >system specific issue: we use perl 5.8.0 and under linux we didn't face this >problem, but now i'm testing with solaris 8 and have lots of packets >"missed". This could be (extra) mutex problems causing the delay. >Sorry, this might be off-topic, but since we experience missed packets, I >might start over again and try using shared memory instead of a Queue. >Thanks for your response, any further hints are welcome :-) ! Well, apparently push() and shift() on shared arrays are supposed to be self-locking. So, you should try throwing out Thread::Queue altogether and just use a shared array with one end push()ing values on to the array and the other end(s) shift()ing them off again. That would lose the overhead of Thread::Queue. Of course, if you're just shift()ing values off the shared array, you might have to adapt your program as it is the equivalent of "dequeue_nb" rather than "dequeue". And this still probably doesn't solve your memory eating problem... Hope this helps, Liz
