j...@resonance.org skrev: > Quoting David Henningsson <launchpad....@epost.diwic.se>: >> >> 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 _______________________________________________ fluid-dev mailing list fluid-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/fluid-dev
