Quoting David Henningsson <launchpad....@epost.diwic.se>:
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?
True. If its all stuffed as events into a queue though and processed from only one point, then it would be serially processed. The lockless queues have the requirement that they can only have one consumer at a time.
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.
Yeah, that could work. Having one outstanding undeleted preset, doesn't seem like a problem. So the delete event queue could be processed when new presets are created, at which point the synth mutex could protect the queue from multiple thread access.
We could also add another thread which runs continuously, checking for items in the delete-preset-queue.
I like your first idea more. I'll see about implementing that.
// David
I'm re-implementing the sfont list as fluid_sfont_info_t structures which have the sfont pointer, refcount and bank offset that we discussed. One of the remaining points of ugliness, is that given an fluid_sfont_t (such as what the fluid_preset_t references), you have to search the list of fluid_sfont_info_t to find the matching one. Not a huge issue I suppose though.
Josh _______________________________________________ fluid-dev mailing list fluid-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/fluid-dev
