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

[Maciej Fijalkowski]

I think it does the locks in the wrong order which means some of them
abort, exiting the function "buggylocking". That means, because we're
not in a with x as lock, we're not cleaning up after the lock until
the __del__ is called. It's possible to fix the "buggylocking" test,
but it's called buggylocking for a reason :-)

On Fri, Apr 1, 2016 at 11:13 AM, Pierre-Yves David
<pierre-yves.david at ens-lyon.org> wrote:
>
>
> On 04/01/2016 12:10 AM, Maciej Fijalkowski wrote:
>>
>> On Fri, Apr 1, 2016 at 9:09 AM, Gregory Szorc <gregory.szorc at gmail.com>
>> 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.
>>
>>
>> So what do we do with lock.__del__ and how tests rely on it?
>
>
> Can we get details about this test failure and why it relies on it?
>
> --
> Pierre-Yves David