We need to keep the mutex around setting it, to make sure that the
visibility of setting it to true doesn't get delayed, notably not after
the signal (which could entail that the signal becomes useless, leading
to a hang).
If a thread is cancelled while it holds a mutex, other threads waiting for
the mutex will never be woken, even if destroying the mutex, thus
leading to a deadlock.
Better just make the thread loops have a proper exit case than risking
the tricky semantic of pthread_cancel.
See issue #8, https://github.com/espeak-ng/espeak-ng/issues/8
There might still be some ints that could be changed to boolean.
Possible regressions in fifo.c:
int fifo_is_busy() and int fifo_is_command_enabled() used to return an int. Now they return a boolean. This might cause problems on systems where stdbool true/false is something else than 1/0.
This is a partial fix for an audio regression. The other part of
the fix requires a change in pcaudiolib to reopen the audio device
on flush requests for affected audio drivers/devices.
This restores the behaviour removed in commit
ca831d236a.
When using eSpeak for audio and eSpeak in a server, using the async
speech requests, that code stopped the audio as soon as possible
from a cancel request. This allows servers like brltty to be more
responsive.
This allows process_espeak_command to stop as soon as possible
Using emacspeak server with espeak-ng (still not published) found that audio was only being stoped after a command is processed (i.e. using pcaudiolib).
This fixes this issue.
If a command ran to completion before the thread calling
fifo_add_command woke up, that thread would wait forever
for the command to start, never realizing that it had already
finished.
The debugging code is done inconsistently, mainly to trace the
event and audio output logic. This makes it harder to understand
the code flow for logic that is not enabled by default.
As such the debugging code makes the code harder to maintain.
Samuel Thibault