[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: David Henningsson
Subject: Re: [fluid-dev] Thread safety long-term thoughts
Date: Wed, 18 Nov 2009 08:13:32 +0100
User-agent: Thunderbird (X11/20090817)

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]