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

[David Henningsson]

address@hidden skrev:
> I've been looking over the SoundFont and preset code in FluidSynth. 
> Here is what I'm currently thinking of doing to resolve the threading
> issues:
> 
> - Add a hash table using the SoundFont ID as the key, which is protected
> by the Synth mutex.
> - Create new structure which is used as values in the hash table, allows
> for additional fields to be applied to SoundFont instances and merge the
> SoundFont bank offset list functionality into it:
> 
> struct _fluid_sfont_priv_t
> {
>   int refcount;
>   int bank_offset;
> };

I would say that we could merge both sfont and bank_offset lists into
that list by including the sfont_t pointer inside it as well.

> - When a Preset is created, a reference is added to its owning SoundFont
> and removed when the preset is destroyed
> 
> - Presets shouldn't be destroyed in synthesis thread, due to memory
> free(), so add another queue which goes in the other direction (synth
> thread to some main thread process), preset destroy events could then be
> sent.

Our idea of calling some preset functions from the main thread and other
preset functions from the synthesis thread is probably necessary, but
should new_fluid_preset and delete_fluid_preset only be called from
under the synth mutex, to make life easier for sf loaders? Or do we risk
callbacks from these and a deadlock?

> Not quite as elegant as I'd like, but I can't think of a better way to
> do it properly and retain the current API.
> 
> I haven't yet thought through, how this "main" or other thread will
> actually go about processing the events sent from the synthesis thread.

Well, I can think of a few ugly solutions. The question is which one is
the least ugly. :-/

> Just wanted to run this by you, to see if you had any better ideas or
> see any problems with it.

I wish I had an elegant solution for you but I can't think of one either.

// David