On Wed, Dec 28, 2005 at 07:14:32PM -0700, Neil Schemenauer wrote:
> [This message has also been posted.]
> Martin v. Löwis <[EMAIL PROTECTED]> wrote:
> > One challenge is that PyObject_GC_Del doesn't know how large the memory
> > block is that is being released. So it is difficult to find out how
>
On Thu, Dec 29, 2005 at 04:22:35AM -0500, Bob Ippolito wrote:
> In this particular case, you might be better off just writing some
> Twisted code that periodically checks the size of the current process
> and does a gc.collect() when necessary. Of course, it requires some
> platform specific
On Wed, Dec 28, 2005 at 05:52:06AM -0800, Aahz wrote:
> If you feel comfortable with C code, the best way to get this to happen
> would be to make the change yourself, then test to find out what effects
I'm more confortable with C code than with python code, that's not the
problem (infact I think
On Wed, Dec 28, 2005 at 03:32:29PM +0100, "Martin v. Löwis" wrote:
> you should really consider comming up with a patch yourself. Bonus
> points if the code integrates with the current strategies, instead
> of replacing them.
As I wrote in the first email, I've no intention to replace anything.
Th
Hello,
I run into a problem recently with a reconnectingclientfactory with
twisted while write some spare time software, that turned out to be a gc
inefficiency.
In short the protocol memory wasn't released after the reconnect and the
protocol had about 50M attached to it. So with frequent reconn
