On Sat, Dec 04, 2004 at 12:48:50AM -0500, Isaac Richards wrote: > > but it should be close enough for others to provide feedback. There > > might be a very tiny race condition, but I think it should be > > inconsequential, and if it turns out not to be, it will hopefully be > > much easier to fix now. > > This actually seems a little more racey to me.
How so? It's true I'm ignoring the problem of using non-atomic operations, but that's already being done (see ff/rewindtime). That leaves normal_speed and audio_stretchfactor as the only things that get changed asynchronously. As long as new_speed is set after them, any missed changes in them will get picked up in the next pass through the loop. > I think a lock just around the > new if clause in the decoder thread, and grabbing that lock anywhere the > tested for values are changed would be in order here. Yeah, that's why I said it would be easier to fix any races now. All of the critical stuff is now done in one place rather than scattered throughout the loop and elsewhere. Previously, it could take multiple locks and passes through the loop for some cases. Whether we add a lock or not, I still think we should strongly consider the change to return early from NVP::GetFrame. Try changing between 1/16 speed and paused to see why. David -- David Engel [EMAIL PROTECTED]
_______________________________________________ mythtv-dev mailing list [EMAIL PROTECTED] http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
