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

[David Henningsson]

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

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?

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

True.

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

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.

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

// David