Dominik Gresch

> I even once looked into the [default parameters](https://stackoverflow.com/a/65995450/1069467) for this... Nice, just looked at these parameters right now 😄 > Of course, it can still be useful to run...

Oh, we should also check if any of the objects in cycles have `__del__` methods: Those won't be collected because it can't figure out the correct order, see https://docs.python.org/3/library/gc.html#gc.garbage Found...

Good point, it's not a _timer_ per se, it's a function of how many objects are allocated / deallocated: > In order to decide when to run, the collector keeps...

But yeah, I'm sure we can come up with a scenario where the number of objects is large, then GC runs (but they're still alive), then the number of objects...

> If everything has finished running then I wouldn't expect the GC to ever run again, because there would be nothing to trigger it. Right, but that is a "testing"...

> yeh fair, well its triggered once a process completes Yeah, I think that's sensible. Looking at https://github.com/aiidateam/plumpy/blob/develop/plumpy/process_comms.py, the `_launch` coroutine also seems like it can complete a process -...

> see my lovely new diagram 😉 Nice 👍 So when is `_launch` used? When using `engine.run` instead of `submit`?

As far as I can see, this doesn't bind either the class or the instance in any way - should there maybe be a `@staticmethod` somewhere to indicate that? From...

Right, I understand the `@staticmethod` isn't actually necessary. What I'm a bit concerned about is that the decorated function _looks_ very similar to a plain method (that would bind `self`),...

> * while doing testing related to this I encountered some weird database errors when a process could not be loaded (e.g. when loading from caching). My guess is that...