4 ms·

Well i'm now working in a hard realtime domain (audio, noone dies when it goes wrong, but it's still hard realtime) and i've still got exceptions turned on. But

Well i'm now working in a hard realtime domain (audio, noone dies when it goes wrong, but it's still hard realtime) and i've still got exceptions turned on. But no exceptions are thrown during runtime, they're there for exceptions. Yes, there's overhead in places, but we noexcept some code paths to reduce that overhead in some very hot code paths.

CyberRabbi 5y ago
If you allow exceptions in your real-time audio loop then when an exception occurs the only useful thing to do would be to take down the entire process. Handling exceptions as a norm in your audio loop would be unacceptable because it could never be done in a way that would always meet the deadline. In that case, if you cannot usefully handle the exception, why have your exceptional situation cause an exception in the first place? You’re just as well off calling abort().
- jcelerier 5y ago
  > If you allow exceptions in your real-time audio loop then when an exception occurs the only useful thing to do would be to take down the entire process. as a user of audio software, I would really prefer them to have the occasional glitch instead of crashing, potentially loosing work. Like, how it is even a discussion ?
  - CyberRabbi 5y ago
    Sure but that isn’t the issue. We’re discussing the architecture of an audio loop, e.g. handling exceptions as a norm in the codebase. If it is avoided then there is no large behavioral difference between calling abort() and throwing an exception.
    - jcelerier 5y ago
      ... I hope I just don't understand. Say you have some audio node in your engine which at some point fails because of some error condition, for instance it tried to load a preset in an invalid format which was supposed to be sanitized beforehand, the preset tried to load a sample and the OS returned -ENOPERM, whatever. Surely you agree that it's better to have this throw an exception, and a big try.. catch around your audio callback so that just this tick, which loads the preset, fails, and then the program continues normally at the next tick, just with the wrong preset for a node, rather than calling abort() which entirely kills the program and looses what the user was working on ?
      - CyberRabbi 5y ago
        > Surely you agree that it's better to have this throw an exception, and a big try.. catch around your audio callback so that just this tick Yes I do agree but my point is that if any exception is being thrown for the sake of being handled then your Audio code is bad. Generally your Audio loop should encounter no errors at all (it should be a pure process) so what the OP is saying is that excepting/aborting is fine in that case because it would truly be exceptional. I can’t imagine what the exceptional situation would be but to the extent one exists, I agree with that. My only point is that throwing an exception when there is no handler is no better than calling abort(), obviating the need for enabling exceptions.
        jcelerier 5y ago
        > Yes I do agree but my point is that if any exception is being thrown for the sake of being handled then your Audio code is bad. thank god ! then we both agree. > Generally your Audio loop should encounter no errors at all (it should be a pure process) and audio handlers should never lock mutexes yet I have seen my fair share of them in the wild. > My only point is that throwing an exception when there is no handler is no better than calling abort() every thread or event loop should always have a catch-all handler at top level.
        CyberRabbi 5y ago
        > and audio handlers should never lock mutexes yet I have seen my fair share of them in the wild. They are incorrect. Only bounded-time synchronization primitives can be used. E.g. lock-free queues. > every thread or event loop should always have a catch-all handler at top level. Two things. 1) There should be no reason for a properly coded real time audio loop to have a top level handler because exceptions should not be thrown because they cannot be guaranteed to be handled within the necessary time constraints. 2) top level exception handlers divorced from context cannot be handled, only ignored. Ignoring exceptions is very dangerous because there is generally no way for the top level handler to be sure that the rest of the program is in a correct state (unless it knows all code is exception-safe, which is rare). Continuing to run can result in data corruption. Exceptions leaving the context that has the information to handle them is a programming error, just like a failed assertion.

CyberRabbi 5y ago

If you allow exceptions in your real-time audio loop then when an exception occurs the only useful thing to do would be to take down the entire process. Handling exceptions as a norm in your audio loop would be unacceptable because it could never be done in a way that would always meet the deadline. In that case, if you cannot usefully handle the exception, why have your exceptional situation cause an exception in the first place? You’re just as well off calling abort().

jcelerier 5y ago
> If you allow exceptions in your real-time audio loop then when an exception occurs the only useful thing to do would be to take down the entire process. as a user of audio software, I would really prefer them to have the occasional glitch instead of crashing, potentially loosing work. Like, how it is even a discussion ?
- CyberRabbi 5y ago
  Sure but that isn’t the issue. We’re discussing the architecture of an audio loop, e.g. handling exceptions as a norm in the codebase. If it is avoided then there is no large behavioral difference between calling abort() and throwing an exception.
  - jcelerier 5y ago
    ... I hope I just don't understand. Say you have some audio node in your engine which at some point fails because of some error condition, for instance it tried to load a preset in an invalid format which was supposed to be sanitized beforehand, the preset tried to load a sample and the OS returned -ENOPERM, whatever. Surely you agree that it's better to have this throw an exception, and a big try.. catch around your audio callback so that just this tick, which loads the preset, fails, and then the program continues normally at the next tick, just with the wrong preset for a node, rather than calling abort() which entirely kills the program and looses what the user was working on ?
    - CyberRabbi 5y ago
      > Surely you agree that it's better to have this throw an exception, and a big try.. catch around your audio callback so that just this tick Yes I do agree but my point is that if any exception is being thrown for the sake of being handled then your Audio code is bad. Generally your Audio loop should encounter no errors at all (it should be a pure process) so what the OP is saying is that excepting/aborting is fine in that case because it would truly be exceptional. I can’t imagine what the exceptional situation would be but to the extent one exists, I agree with that. My only point is that throwing an exception when there is no handler is no better than calling abort(), obviating the need for enabling exceptions.
      - jcelerier 5y ago
        > Yes I do agree but my point is that if any exception is being thrown for the sake of being handled then your Audio code is bad. thank god ! then we both agree. > Generally your Audio loop should encounter no errors at all (it should be a pure process) and audio handlers should never lock mutexes yet I have seen my fair share of them in the wild. > My only point is that throwing an exception when there is no handler is no better than calling abort() every thread or event loop should always have a catch-all handler at top level.
        CyberRabbi 5y ago
        > and audio handlers should never lock mutexes yet I have seen my fair share of them in the wild. They are incorrect. Only bounded-time synchronization primitives can be used. E.g. lock-free queues. > every thread or event loop should always have a catch-all handler at top level. Two things. 1) There should be no reason for a properly coded real time audio loop to have a top level handler because exceptions should not be thrown because they cannot be guaranteed to be handled within the necessary time constraints. 2) top level exception handlers divorced from context cannot be handled, only ignored. Ignoring exceptions is very dangerous because there is generally no way for the top level handler to be sure that the rest of the program is in a correct state (unless it knows all code is exception-safe, which is rare). Continuing to run can result in data corruption. Exceptions leaving the context that has the information to handle them is a programming error, just like a failed assertion.