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

[josh]

Quoting David Henningsson <address@hidden>:
> > 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.

Good point.  We could just use a list, rather than a hash, and merge  
the sfont list as well.  Might not be all that efficient once you  
reach 2048 SoundFont files though ;)  So I'm leaning towards using a  
hash table, since refcounting will probably end up being a somewhat  
frequent operation, though I imagine the efficiency wouldn't pay off  
until a dozen or more SoundFont files are loaded, which is probably  
unlikely.

> 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?


I don't see how that would make life easier for SoundFont loaders.   
Allocating or destroying a fluid_preset_t is pretty independent of any  
other operations.  If a SoundFont loader needs to do its own locking,  
that would be up to it.

Deadlocks are something to keep in mind though.  We could use a  
GStaticRecMutex instead, which allows for recursive locking.  I'm not  
certain what use cases might require calling a FluidSynth function  
from within an SoundFont loader method though.  I'm also not sure  
which methods might even require a mutex lock, perhaps its a non  
issue, if none of them need to use the synth mutex.


> > 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. :-/


The ugly part to me is delete_fluid_preset, in regards to events  
getting passed back to some other non-synthesis thread.  Still need to  
figure out how that thread is created or how those events get processed.


> > 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

Ok.  I feel more confident then, to continue on the same path :)

Cheers!

Josh