Re: [fluid-dev] Thread safety long-term thoughts

[David Henningsson]

Ebrahim Mayat wrote:
> Currently, fluidsynth has five threads.
>
> 5 process 6014 thread 0x6f03  0x936a11f8 in mach_msg_trap ()
> 4 process 6014 thread 0x6703  0x936a1278 in 
> semaphore_timedwait_signal_trap ()
> 3 process 6014 thread 0x6203  0x936a11f8 in mach_msg_trap ()
> 2 process 6014 thread 0x1003  0x936a7c0c in __semwait_signal ()
> * 1 process 6014 thread 0x10b  0x936ae6b8 in read$UNIX2003 ()
>
> Of these threads the shell process (fluidsynth.c) is the first one. The 
> second thread begins with fluid_synth_return_event_process_thread which 
> together with fluid_synth_one_block are declared in fluid_synth.c
>
> The other three threads (please correct me if I am wrong) address the 
> audio, MIDI and I/O procs.
>
> How does the state machine and voice renderer fit into this picture ?

Hi Ebrahim and thanks for the thread overview; it's nice to have that 
point of view as well.

A difference between 1.0.9 and 1.1.0 is that the audio thread got more 
of the state machine work to do; making it harder to keep its real-time 
properties. I admit to not having considered this well enough when we 
discussed the thread safety the previous time.

So I want to give the audio thread as little to do as possible, to make 
it as easy as possible to avoid xruns. The audio thread is proposed to 
do just the voice renderer work, not the state machine work (which it 
does in 1.1.0).

The midi thread and shell threads will do the state machine work, when 
they make calls against the fluid_synth object.

The return event queue thread is mainly used for garbage collection, 
when the audio thread leaves garbage behind that cannot be collected 
within a fixed enough time. Hopefully it can be removed if the audio 
thread gets less to do, but I'm not certain about this.

I'm not sure about the fifth (I/O procs) thread, is that something used 
internally by libraries we use? What does it do?

// David