thread-check: apply doc changes and format the file

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.