Closed krasznaa closed 6 months ago
The "SEH exceptions" on Windows turned out to come from this:
https://forums.developer.nvidia.com/t/accessing-managed-memory-during-asynchronous-copies/
So I just disabled some tests on Windows...
With the conclusions coming out of
https://forums.developer.nvidia.com/t/accessing-managed-memory-during-asynchronous-copies/
I considered for a bit if the vecmem::copy
code could potentially detect when it can and can't do certain copy operations asynchronously. But in the end, that would be super difficult to do. (The "copy code" should not know what type of memory resources it is dealing with.) So let's just stay with disabling some of the tests on Windows, and then remembering this limitation in case some user stumbles upon it in the future.
Managed to hit "Enter" with my pinkie a bit too early... :frowning:
This is a follow-up from #268.
vecmem::abstract_event::ignore()
function, to allow clients to explicitly ignore a given synchronization event in their code if they want to. (In some rare cases this can be useful.)::sycl_event
and::cuda_event
implicitly wait for their underlying events in their destructors, if the user didn't do so explicitly.VECMEM_FAIL_ON_ASYNC_ERRORS
CMake option for building the project in a way that it would call std::terimate() in case it detects such an error. After considering throwing an exception at first, I went with callingstd::terminate()
in the end, because throwing exceptions in destructors "cleanly" is just a lot of hassle. I still needed to do something "drastic", since the way that we build the project, with pretty aggressive symbol hiding, there is no easy way of debugging such issues in a client project easily without the code doing something "drastic". :thinking:vecmem::copy
becoming yet a bit more complicated. In order to avoid "internal waits" in its functions as much as possible.With all of this in place, all copy related issues are gone from my tests now... :crossed_fingers: