Re: Empirically setting a screen reader delay
@Ethin: he doesn't need a mutex on counter. I'm assuming that code is its own function in which case there is no sharing of state there. You don't need to make counter reside in global scope for this. So the code is thread-safe.
As for the first point you mentioned, he can wait on a notify event that will block the thread until the screen-reader starts speaking. So the function can provide a guarantee that once the code enters the loop, the screen-reader has definitely started speaking so there's no race condition to contend with.
My original point still stands though: that of timing. Even with 10 ms delay, it's theoretically still possible to incorrectly state that the screen-reader has finished speaking. Any type of delay-check-delay-check pattern on periodic data runs this type of risk, and vocals are definitely periodic data.
-- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
