[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[fluid-dev] Re: FluidSynth event queue and thread safety changes
From: |
David Henningsson |
Subject: |
[fluid-dev] Re: FluidSynth event queue and thread safety changes |
Date: |
Wed, 26 Aug 2009 11:29:48 +0200 |
User-agent: |
Thunderbird 2.0.0.23 (X11/20090817) |
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
- [fluid-dev] FluidSynth event queue and thread safety changes, josh, 2009/08/17
- [fluid-dev] Re: FluidSynth event queue and thread safety changes, David Henningsson, 2009/08/19
- [fluid-dev] Re: FluidSynth event queue and thread safety changes, josh, 2009/08/19
- [fluid-dev] Re: FluidSynth event queue and thread safety changes, David Henningsson, 2009/08/23
- [fluid-dev] Re: FluidSynth event queue and thread safety changes, josh, 2009/08/23
- [fluid-dev] Re: FluidSynth event queue and thread safety changes, David Henningsson, 2009/08/23
- [fluid-dev] Re: FluidSynth event queue and thread safety changes, josh, 2009/08/23
- [fluid-dev] Re: FluidSynth event queue and thread safety changes, josh, 2009/08/26
- [fluid-dev] Re: FluidSynth event queue and thread safety changes,
David Henningsson <=
- [fluid-dev] Re: FluidSynth event queue and thread safety changes, josh, 2009/08/26
- [fluid-dev] Re: FluidSynth event queue and thread safety changes, David Henningsson, 2009/08/27
- [fluid-dev] Re: FluidSynth event queue and thread safety changes, josh, 2009/08/27
[fluid-dev] Re: FluidSynth event queue and thread safety changes, David Henningsson, 2009/08/22