[PATCH rfc] rfc: call gc at exit of mercurial

Augie Fackler raf at durin42.com
Tue Apr 5 13:23:54 EDT 2016


On Fri, Apr 01, 2016 at 12:09:19AM -0700, Gregory Szorc wrote:
>
>
> > On Mar 31, 2016, at 23:58, Maciej Fijalkowski <fijall at gmail.com> wrote:
> >
> > # HG changeset patch
> > # User Maciej Fijalkowski <fijall at gmail.com>
> > # Date 1459493914 -7200
> > #      Fri Apr 01 08:58:34 2016 +0200
> > # Node ID 66b3737b62635691b5a205dafc80e640880b77ca
> > # Parent  9ca7854b963295b8b56d276b903623ac8277f18d
> > rfc: call gc at exit of mercurial
> >
> > This is not a proper patch, just a visualization of a hack I did.
> > Locks have a __del__, which test-devel-warnings rely on being
> > called at the exit of a program. Locks also have __exit__ which is
> > a more proper way to handle locks, but that test does not respect it.
> > I would like to know what's the proper way of handling this - should
> > I fix test, should I just call the GC (which will make the command
> > line tool slower) or what's the proposed solution
>
> __del__ should be purged and banned from the code base because it undermines GC and can lead to memory leaks.
>
> For holding on to temporary resources, context managers (preferred) or try..finally should be used.

Having read most of the rest of this thread, I think this is the
direction I'd like us to go. Does anyone know how hard/impossible it
would be to move all our locks to only be context managers?

>
> >
> > diff -r 9ca7854b9632 -r 66b3737b6263 hg
> > --- a/hg    Thu Mar 31 18:38:08 2016 +0200
> > +++ b/hg    Fri Apr 01 08:58:34 2016 +0200
> > @@ -40,4 +40,8 @@
> > for fp in (sys.stdin, sys.stdout, sys.stderr):
> >     mercurial.util.setbinary(fp)
> >
> > -mercurial.dispatch.run()
> > +try:
> > +    mercurial.dispatch.run()
> > +finally:
> > +    import gc
> > +    gc.collect()
> > _______________________________________________
> > Mercurial-devel mailing list
> > Mercurial-devel at mercurial-scm.org
> > https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
> _______________________________________________
> Mercurial-devel mailing list
> Mercurial-devel at mercurial-scm.org
> https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel


More information about the Mercurial-devel mailing list