Replies: 2 comments 7 replies
-
In a discord convo with @abique he tells me that yes, the intent is definitely that request_flush is always safe, and so this should be a spec documentation update, not a host behavior update. |
Beta Was this translation helpful? Give feedback.
1 reply
-
I've clarified the documentation on the next branch. |
Beta Was this translation helpful? Give feedback.
6 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
This thread is a result of a conversation with @robbert-vdh @signaldust Urs and myself on KVR at https://www.kvraudio.com/forum/viewtopic.php?p=8453301#p8453301
The essence of the question was: When processing is stopped a plugin should call
request_flush
. How do you communicate processing is stopped so that can happen without a race.One such approach is
std::atomic<bool>
which you update in start/stop processingbut @signaldust rightly points out that if processing resumes before the request flush, then the request flush will happen with processing active, which the spec says is not necessary.
I think the spec is ambiguous in this regard. The documentation says
I propose we add a sentence
If processing is active when request_flush is called, the call is ignored
. I think we should add that because (1) it is what happens I believe and (2) it allows you to easily write a race free implementation using an atomic and a timer, as discussed on that KVR threadReading the sample
clap-host
it seems that request_flush does the following (void PluginHost::clapParamsRequestFlush
)From this I conclude calling refresh_flush repeatedly with processing going will result in nothing happening until processing stops and then will have one call to flush from the idle thread. I think this is reasonable behavior, but the spec is silent.
I think making request_flush strictly a no-op when processing is going (which would mean basically untoggle that state in the idle loop I think in the clap host) is a better spec, I think its what we intended, and I think we can update the doc accordingly
But if it isn't a better spec, and isn't what we intended, then lets figure out what is and clean up the spec doc some for a future dot release!
Beta Was this translation helpful? Give feedback.
All reactions