Alpaka: Destructors should not throw

[theZiz]

Colleagues from the DLR using Alpaka run into a problem while using Alpaka together with a singleton pattern, in which a single global class handles the program environment.

Independently whether one should use this pattern or not, CUDA has problems with global variables as the may destruct after the cuda driver is already shut down: https://stackoverflow.com/questions/40979060/cudaerrorcudartunloading-error-29-due-to-driver-shutting-down

So in the end ALPAKA_CUDA_RT_CHECK fails with an unhandled exception: https://github.com/ComputationalRadiationPhysics/alpaka/blob/develop/include/alpaka/stream/StreamCudaRtSync.hpp#L103

As it is not possible to catch these exceptions destructors should normally not throw, but the class should have explicit finishinig / closing methods which can be checked for errors (if wanted), see https://stackoverflow.com/questions/130117/throwing-exceptions-out-of-a-destructor .

So I suggest to make every destructor of Alpaka non-throwing, e.g. by catching all exceptions inside the destructor so that error messages from ALPAKA_CUDA_RT_CHECK still appear.

[BenjaminW3]

The easiest solution should be to add try-catch blocks for all CUDA object wrapper destructors. I think this should be ok.

[psychocoderHPC]

In PIConGPU and Cupla we have a Singleton which load something like a parallel environment. This is the first singleton which is initialized and therefore also the last which will be destroyed. This class initialize and destroy the accelerator context.

[ax3l]

Note: we recently just introduced non-throwing, stderr-only-writing equivalents for those macros in PIConGPU. As a quick-fix that might be good as well. Nevertheless, clean functors and environment/device control that does not depend on destructor-order is the thing we should impl on the long run.

[sbastrakov]

As a quick-fix that might be good as well

I agree with that. However, I think even the "new" approach in PIConGPU is not that good. Now the throwing versions of the check macros do both reporting (e.g., prints to stderr) and exception generation. And these two have actually nothing to do with one another and so are better be decoupled. C++ exceptions generally offer that: in case errors are reported as exceptions (so e.g., everywhere on the host side except in destructors), and the latter proparaged properly throughout the code, the reporting could be done somewhere way outside the place an exception is generated. Then a place which does the actual reporting could have more flexibility of how it's implemented and could have access to more context.

[ax3l]

Yes, fully agree. Nevertheless, we cannot throw in noexcept contexts such as destructors, where we still have to log. So all the C++ niceness does not help here, unless refactored out of destructors, as suggested.