Finally I have a valgrind log that someone can maybe look at and advise how we can get this issue addressed. If this log is insufficient, please advise how I can get another one done up for analysis.
. . . . . Wesley On Fri, Oct 24, 2008 at 10:52 AM, Juliusz Chroboczek < juliusz.chroboc...@pps.jussieu.fr> wrote: > > Juliusz (or any other adventurous developer on this list): have you > > considered using libmemcached instead of the file system for storing your > > cache? > > No. The data structures of Polipo are finely tuned, unless you can provide > benchmarks that show that memcached is faster than the built-in code, I see > no reason to switch. > > > And I hear that it scales pretty well :) > > The in-memory cache of Polipo runs in O(log n), except in the case of > emergency allocations (being short on memory). > > > Also, I am finding that some of my polipo instances are silently > crashing, > > and I am looking for a way to track what is causing this. > > 1.0.4 has a number of known bugs. My current tree fixes some of the known > bugs, but introduces new ones. > > Right now, I've got my hands full with other stuff (such as Real Work(TM)). > Sorry for that. > > Juliusz >
valgrind.RU.log
Description: Binary data
------------------------------------------------------------------------------ The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your production scanning environment may not be a perfect world - but thanks to Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700 Series Scanner you'll get full speed at 300 dpi even with all image processing features enabled. http://p.sf.net/sfu/kodak-com
_______________________________________________ Polipo-users mailing list Polipo-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/polipo-users
