[fluid-dev] Re: FluidSynth event queue and thread safety changes

[josh]

Quoting David Henningsson <address@hidden>:

> I can think of some reasons why a soundfont loader does not want
> simultaneous delete_fluid_preset's, especially if they relate to the
> same soundfonts. What was the case with 1.0.9, were those calls
> synchronized?

True.  If its all stuffed as events into a queue though and processed  
from only one point, then it would be serially processed.  The  
lockless queues have the requirement that they can only have one  
consumer at a time.

> One of the half-ugly solutions would be to process the
> delete-preset-queue only when we get another set_preset call, or sf
> unload call. Or possibly add more places. We should then protect the
> queue reader with a mutex.

Yeah, that could work.  Having one outstanding undeleted preset,  
doesn't seem like a problem.  So the delete event queue could be  
processed when new presets are created, at which point the synth mutex  
could protect the queue from multiple thread access.

> We could also add another thread which runs continuously, checking for
> items in the delete-preset-queue.

I like your first idea more.  I'll see about implementing that.

> // David

I'm re-implementing the sfont list as fluid_sfont_info_t structures  
which have the sfont pointer, refcount and bank offset that we  
discussed.  One of the remaining points of ugliness, is that given an  
fluid_sfont_t (such as what the fluid_preset_t references), you have  
to search the list of fluid_sfont_info_t to find the matching one.   
Not a huge issue I suppose though.

Josh