Non-user threads in output modules

[Hynek Hanke]

" * If one or more new threads are used in the output module, they
must block all signals."
> My question is what about the threads used by the TTS system
> internally? For example, espeak uses a separate thread to call the
> callback function for delivering synthesis events. The developer of
> the output module does not have control over the properties of such
> threads.

Hi Lukas,

I think in such a case either it is mentioned in the documentation of
the TTS system or we should ask the author to fix it.

> Does the above requirement also apply to threads used by the
> TTS system? 

All threads in the process of the output module.

> What is the reason for the above requirement?

Threads and signals generally mix very badly. If a signal is delivered
to a process running multiple threads, it depends on the platform if
only one thread receives the signal (and worse, it can sometimes be
picked randomly) or if all threads receive it. So if we allow users or
controlling processes to send signals, it is very important for all but
one thread in the process to receive signals.

Speech Dispatcher currently doesn?t use signals for anything and we don
?t plan it, so this requirement is not essential, but the modules can be
run as standalone processes. It might not be unreasonable for the user
to send e.g. SIGTERM to such a process. If in such a case eSpeaks
internal thread tries to handle SIGTERM instead of the main module
thread (which should just cleanly exit), bad things might happen.

Unless I?m wrong, I think this is a general concern with threading
programs, so I think it is a bug if eSpeaks internal threads do not
block signals.

Have a nice day,
Hynek