[Scummvm-devel] thread safe container objects (Was: [Scummvm-cvs-logs] SF.net SVN: scummvm: [28914] scummvm/trunk/engines/lure/res_struct.h)

Paul Gilbert paulfgilbert at gmail.com
Mon Sep 17 02:14:45 CEST 2007


Hi Max,

In retrospect, you're right. I originally did the re-ordering as a
preventative measure to prevent the sound system onTimer from accessing the
playing sounds list that might be in the middle of an update. But even
scanning through the list could cause problems if it interrupts the main
thread in the middle of a delete and update of the list. I guess I'll have
to add a mutex in just to be on the safe side.

Speaking of which, could anyone familiar which the MidiParser classes tell
me if it's possible to reduce the number of channels it requires? Currently,
each parser seems to take up 8 channels, even if it's parsing a MIDI file
with only a single MTrk. In the case of Lure of the Temptress, all sounds
are MIDI tracks, so it's currently causing some problems when multiple
sounds are playing.. I'm currently partially overlapping the channels, but
this causes some interference.

Paul.

On 9/16/07, Max Horn <max at quendi.de> wrote:
>
>
> As it is, I think the change is problematic, because instead of
> fixing the problem, it just hides it / makes it less likely to be
> triggered. So, assuming the old code was causing buggy behavior, you
> just went from a hard-to-catch bug to a near-impossible-to-catch
> "heisenbug", which IMO makes things worse, not better :-(.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.scummvm.org/pipermail/scummvm-devel/attachments/20070917/71e4f949/attachment.html>


More information about the Scummvm-devel mailing list