You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It looks like the implementation of DebugDevice::newObjectHandle is not thread-safe. So I was wondering: Does the debug layer fully support the ANARI_KHR_DEVICE_SYNCHRONIZATION extension (given the wrapped device does support it)?
I am asking because I am observing occasional segfaults in multi-threaded application code that constructs ANARI scene objects.
The text was updated successfully, but these errors were encountered:
It currently isn't thread safe, but really should be. The visgl device takes an approach that would work generically by putting all ANARI calls on a background thread, but that would need to be ported to the debug device. It's actually possible for that to be a generic layer, making it usable in more contexts. This is a good request to prioritize -- we will see where this can be worked on, but no time estimate just yet.
Thanks. This is not urgent. I can continue without the debug layer for some time.
I had hoped that it would be sufficient to simply guard the DebugDevice::objects and DebugDevice::objectMap fields against concurrent accesses using an internal mutex. But maybe that would cost too much performance or the situation is more complicated than I think. I have not delved any deeper into the inner workings of the debug layer.
It looks like the implementation of
DebugDevice::newObjectHandle
is not thread-safe. So I was wondering: Does the debug layer fully support theANARI_KHR_DEVICE_SYNCHRONIZATION
extension (given the wrapped device does support it)?I am asking because I am observing occasional segfaults in multi-threaded application code that constructs ANARI scene objects.
The text was updated successfully, but these errors were encountered: