On Saturday 04 December 2004 02:03 am, David Engel wrote: > 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 thought the entire point of breaking everything for this was to protect against those changes being made async? The bigger issue, though, is that there's a _lot_ of code that assume that NVP::Pause blocks until certain threads are paused, which isn't true with this patch anymore. > 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. As long as it sleeps in GetFrame for a bit. Isaac _______________________________________________ mythtv-dev mailing list [EMAIL PROTECTED] http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev