Non-deterministic objects destruction in unit tests and demos

[Jan Blechta]

As a workaround to #390 we should avoid using explicit del in tests/demos. There a lot of patterns like

        xdmf = XDMFFile(mesh.mpi_comm(), filename)
        xdmf.write(mesh)
        del xdmf

del does not ensure calling object destructor. So there should be

1. either xdmf.close(),
2. or keeping xdmf in scope until a test function returns and teardown invokes gc.collect() automatically.

[Jan Blechta]

Or equivalent to 1. with XDMFFile(mesh.mpi_comm(), filename) as xdmf:

[Miklós Homolya]

del just removes the reference, thus decreases the reference count. If the reference count reaches zero, the object is freed immediately (calling __del__ first if defined). In case of reference cycles, the object may be freed at some point when Python secondary garbage collector runs. If any of the objects in a reference cycle has __del__ defined, then the objects of that cycle are never freed because Python does not know in which order to run the destructors.

with statement is the Pythonic way of allocating and freeing resources.

[Jan Blechta]

If the reference count reaches zero, the object is freed immediately

Could you give some reference to this. I believe that this is not true which is why we are struggling with collective destructors causing problems. I thought that garbage collectors is allowed to deallocate the object any time it decides to do so (unless you call gc.collect() assuming there are no cycles).

[Miklós Homolya]

CPython implementation detail: CPython currently uses a reference-counting scheme with (optional) delayed detection of cyclically linked garbage, which collects most objects as soon as they become unreachable, but is not guaranteed to collect garbage containing circular references. See the documentation of the gc module for information on controlling the collection of cyclic garbage. Other implementations act differently and CPython may change. Do not depend on immediate finalization of objects when they become unreachable (so you should always close files explicitly).

Souce: https://docs.python.org/3/reference/datamodel.html

[Jan Blechta]

as soon as they become unreachable

is only vaguely interpreted as immediately.

Do not depend on immediate finalization of objects when they become unreachable

[Jan Blechta]

Mention demos too.

[Jan Blechta]

Most of the explicit del instances taken care of by @trlandet. I will clean the rest afterwads. Implicit deletion (by becoming unreachable) is worse. Need to go through the tests line-by-line I guess. Typical case

def test_foo():
    x = Vector()

    # Do something with x

    x = Vector()  # original vector eventually deleted

[Jan Blechta]

Partial fixes for this in pull request #338 to be merged after 2017.1 release.