Re: [fluid-dev] Some more thread safety commits and stuff

[josh]

Quoting David Henningsson <address@hidden>:
> address@hidden skrev:
> > Added SoundFont reference counting, presets now add references to
> > SoundFonts.  SoundFonts are only unloaded after all presets relinquish
> > their references.
>
> When a soundfont is unloaded (e g by a shell command), will the channels
> somehow receive a message and unload their current presets or will the
> soundfont stay in memory until they give up their presets?

In fluid_synth_sfunload a call to fluid_synth_program_reset or  
fluid_synth_update_presets is called, which will relinquish the  
presets.  The difference from before, is that this will now be queued,  
rather than done immediately.  This means that fluid_synth_sfunload  
will almost always spawn a thread to periodically attempt to unload  
the SoundFont (which will succeed once all presets are unloaded).   
Perhaps the synthesis thread could instead send an event in the return  
queue, when the SoundFont can be unloaded instead, which would be  
cleaner.

Of note, is that I still haven't added the preset un-reference code or  
the synthesis thread -> regular thread queue code, so SoundFont files  
will currently not unload.  Its next on my list to implement this.

> > I realize now that we have probably missed the Ubuntu deadline that
> > David had mentioned.
>
> The Karmic deadline is probably missed, yes. Next deadline for Ubuntu is
> in December. (There were discussions that Debian would freeze in
> December as well, but I'm not sure whether that it will actually be that
> way.) I will need some time to work on the packaging as well, so some
> margin would be appreciated.
>
> I don't want the FluidSynth project to feel chained to these deadlines
> though - there are a lot more distributions and OSes that FluidSynth is
> a part of.
>
> > In hindsight, we should probably have released a
> > 1.0.10 without the more ambitious thread safety changes.  I'm going to
> > continue plugging away at making FluidSynth thread safe, which I think
> > we are close to now, but we should perhaps still consider the option of
> > releasing a 1.0.10 version. When the thread safe changes are complete,
> > there is likely a bit of testing that is in order to make sure there
> > aren't any issues, since the changes are not so trivial.
>
> If we look back in time, I see all the bugs we've fixed and the new
> functionality we've implemented, so it would be great if the rest of
> FluidSynth community could enjoy that as well! I strongly support
> releasing a new version, the sooner the better. (Given that we test it
> first, of course.)
>
> > As to the previous discussion about glib dependency.  I have once again
> > flip-flopped on my decision.  It seems to me that the features we want
> > to use from glib are minimal (hash tables, lists and threading related
> > data types).
>
> That's not completely true; it might be the only features we currently
> use, but if we start to use glib we can start to use it for more things.

True.  I don't see needing a lot more of its functionality for the  
core of FluidSynth though.  I guess I'm still trying to satisfy  
multiple use cases.  It would be the easiest to just go glib as far as  
development is concerned, but the "abort when out of memory" issue  
coupled with the added dependencies it causes, may be worth the effort  
to try and keep FluidSynth standalone or at least have an option of  
being stand alone.

> > Testing results on the fluidsynth_event_queue branch would be
> > appreciated!
>
> Sure.
>
> > Perhaps we should merge it back into trunk soon?
>
> To me, the branch has actually always been stable enough to merge into
> trunk. And if there are remaining bugs, the sooner we find them, the
> better. So feel free to merge it when you want to.

Ok.  I'll finish implementing the SoundFont unloading and return queue  
and then merge it into trunk.

> // David

Cheers!

Josh