Making use of smart-pointers in the future would very probably solve your problem. But it would require to use smart-pointers for every ressource that t8code is using, which might not always be the best choice.
Maybe it is possible to create such a function only for the interface? I think most of the t8code-objects such as forest, cmesh, etc. provide a t8_*object_name*_destroy function. Is there an option in julia to somehow keep track of allocated resources and then call the destroy-functions for those?

I think most of the t8code-objects such as forest, cmesh, etc. provide a t8_*object_name*_destroy function. Is there an option in julia to somehow keep track of allocated resources and then call the destroy-functions for those?

In general, this is possible and already thought of such a solution. However, such an approach would interfere with the lifetime of such objects - basically keeping them alive till the application shuts down. This is not desirable since Julia's garbage collector should be able to destroy t8code mesh/forest objects at its own discretion.

I think most of the t8code-objects such as forest, cmesh, etc. provide a t8_object_name_destroy function.

Exactly these destroy functions are called in the finalizers on Julia side. However, as already pointed out, the decision when these finalizers are called, is up to the garbage collector.

We just had a lengthy discussion about this in the t8code developer's meeting.

Globally tracking memory allocations throughout the whole t8code code base would be a laborious, error-prone task with potentially accompanying performance degradation.

Fortunately, our suspicion is that just keeping track of allocated MPI shared memory covers a lot of use cases already. Providing a global clean-up routine for this is a feasible task.

Hi guys! This sounds like a tricky-to-get-right feature @jmark, and I really don't know if it is possible to ship something that will make everyone happy...
In my view, the root problem here is that C, (modern) C , and Julia rely on 3 different approaches to ressource management:

• C mandates destruction/deallocation functions which must be called by the user. This is a static and explicit approach
• C is technically built on the same principles, but idiomatic C introduces RAII wrapper classes to abstract these concerns, so that destruction is done automatically based on scope. This is a static but implicit approach, which can easily coexist with the C approach, except maybe in a few pathological cases. However, supporting both APIs imply strict restrictions on the lifetime semantics that can actually be implemented.
• Julia (like Python and other interpreted/JIT languages) is a garbage-collected language. It does not provide any guarantee on when it deallocates stuff, other than "when it is not needed anymore". This approach is purely dynamic, and is in stark contrast with the C and C approaches.

I don't claim to know the right way to make this work, but here are some of the lessons I have learned (sometimes the hard way) when designing Python APIs for the C code I work with (which uses t8code and indirectly has to answer the same kind of questions):

• Embrassing RAII, and more generally speaking value semantics, goes a long way towards taming the garbage-collector. The ideal case is to have very clear whole-part relationships between all the components available through the API, so that all the destruction/deallocation logic can be handled deterministically in the C/C layer and without user intervention, because the guarantees are much stronger there. The goal being that, no matter the order in which the garbage-collector tries to delete the different objects, each object is effectively destroyed in the right order without loose ends or circular ownership patterns left in the end. In other words, when there is a coupling between multiple components (deallocation-wise), the coupling must be addressed in C/C , and one of the components should be responsible for deallocating both itself and the other (in the right order), while the second should behave like a non-owning handle. I would expect that making this happen would require a lot of refactoring and redesigning work in t8code, and would lead to lots of breaking changes, because the current semantics are quite far from that.
• A functional design based on immutable objects is also very helpful for such purposes. In some cases this is neither easy to implement nor intuitive to use, and there are tradeoffs to be made. I believe however that this is already well-aligned with the current design of t8code in the sense that, if you want to adapt a forest for example, you effectively construct a new forest (at least logically speaking, I reckon that there might be some COW implemented under the hood to speed things up).

The point I'm trying to articulate here is that this issue should be considered in the broader discussion of
t8code's migration towards more modern C , because whether the migration is meant to be a small surface refactoring or will include semantic revisions and redesigns, will greatly influence how to proceed here. For example, if the C API is to be supported in the long run, as a lower-level alternative to the main C API, this effectively retrains a lot what can be done to address this issue within t8code. I would expect that a pure C wrapper of t8code would be needed on the Trixi side to address the impedance mismatch in that case.

@cburstedde I would say that yes, since what you suggest effectively boils down - if I understand your comment correctly - to supporting two disjoint APIs:

• the original C-style API where the user is responsible for calling the cleanup code
• a higher-lever API which automates the cleanup

If you can guarantee that the two are never mixed together, which I believe is achievable with a good design, then I don't see a reason why this approach wouldn't work. This strategy can effectively be described as having the wrapper be part of the t8code repo. In C , building such an abstraction layer on top of the existing t8code API is not very difficult since (except for a few functions) it is quite straightforward to wrap the current API into a handful of RAII types. Indeed, since all the objects are already reference counted, enforcing correct deallocation order is really just a matter of making sure that each objects holds a reference to its direct parent: elements keep their forest alive, forests keep their cmesh alive, and cmeshes keep the global module handle alive basically. If you wish to keep a pure C codebase however, I really don't know how feasible this is...