diff --git a/include/clap/ext/thread-check.h b/include/clap/ext/thread-check.h index 255242d8..493e192d 100644 --- a/include/clap/ext/thread-check.h +++ b/include/clap/ext/thread-check.h @@ -17,15 +17,16 @@ extern "C" { /// This will be the same OS thread throughout the lifetime of the plug-in. /// On macOS and Windows, this must be the thread on which gui and timer events are received /// (i.e., the main thread of the program). -/// It isn't a realtime thread, yet this thread needs to respond fast enough to allow user interaction, -/// so it is strongly recommended plugins run long,and expensive or blocking tasks such as preset indexing -/// or asset loading in dedicated background threads started by the plugin. +/// It isn't a realtime thread, yet this thread needs to respond fast enough to allow responsive +/// user interaction, so it is strongly recommended plugins run long,and expensive or blocking +/// tasks such as preset indexing or asset loading in dedicated background threads started by the +/// plugin. /// /// audio-thread: -/// This thread can be used for realtime audio processing. Its execution should be as deterministic -/// as possible to meet the audio interface's deadline (can be <1ms). There are a -/// known set of operations that should be avoided: malloc() and free(), contended locks and mutexes, -/// I/O, waiting, and so forth. +/// This thread can be used for realtime audio processing. Its execution should be as +/// deterministic as possible to meet the audio interface's deadline (can be <1ms). There are a +/// known set of operations that should be avoided: malloc() and free(), contended locks and +/// mutexes, I/O, waiting, and so forth. /// /// The audio-thread is symbolic, there isn't one OS thread that remains the /// audio-thread for the plugin lifetime. A host is may opt to have a @@ -42,15 +43,18 @@ extern "C" { /// If a plugin doesn't implement render, then that plugin must have all [audio-thread] functions /// meet the real time standard. If the plugin does implement render, and returns true when /// render mode is set to real-time or if the plugin advertises a hard realtime requirement, it -/// must implement realtime constraints. Host provided [audio-thread] functions can be called -/// from a plugin on the audio thread and must also therefore either meet the real-time constraint, -/// not run plugins which advertise a hard realtime constraint via render or don't implement render, -/// or expect potentially inconsistent rendering and performance from plugins when they re-enter the host. +/// must implement realtime constraints. Hosts also provide functions marked [audio-thread]. +/// These can be safely called by a plugin in the audio thread. Therefore hosts must either (1) +/// implement those functions meeting the real-time constraints or (2) not process plugins which +/// advertise a hard realtime constraint or don't implement the render extension. Hosts which +/// provide [audio-thread] functions outside these conditions may experience inconsistent or +/// inaccurate rendering. /// -/// Clap also tags some functions as [thread-safe]. Functions tagged as [thread-safe] can be called from -/// any thread unless explicitly counter-indicated (for instance [thread-safe, !audio-thread]) and may -/// be called concurrently. Since a [thread-safe] function may be called from the [audio-thread] unless -/// explicitly counter-indicated, it must also meet the realtime constraints as describes above. +/// Clap also tags some functions as [thread-safe]. Functions tagged as [thread-safe] can be called +/// from any thread unless explicitly counter-indicated (for instance [thread-safe, !audio-thread]) +/// and may be called concurrently. Since a [thread-safe] function may be called from the +/// [audio-thread] unless explicitly counter-indicated, it must also meet the realtime constraints +/// as describes above. // This interface is useful to do runtime checks and make // sure that the functions are called on the correct threads.