[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: josh
Subject: Re: [fluid-dev] Some more thread safety commits and stuff
Date: Mon, 14 Sep 2009 11:24:19 -0700
User-agent: Internet Messaging Program (IMP) H3 (4.1.6)

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


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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]