gnash-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Gnash-dev] Re: [Gnash-commit] [SCM] Gnash branch, master, updated. 6895


From: Sandro Santilli
Subject: [Gnash-dev] Re: [Gnash-commit] [SCM] Gnash branch, master, updated. 6895d3b0542e1ac28a3e37dd150187dacb66195d
Date: Tue, 24 Aug 2010 22:25:36 +0200

On Tue, Aug 24, 2010 at 11:42:16AM -0700, John Gilmore wrote:
> > --- a/libmedia/MediaParser.cpp
> > +++ b/libmedia/MediaParser.cpp
> > @@ -411,6 +411,12 @@ MediaParser::parserLoop()
> >     while (!parserThreadKillRequested())
> >     {
> >             parseNextChunk();
> > +           gnashSleep(100); // thread switch 
> > +
> > +           // check for parsing complete
> > +           // TODO: have a setParsingComplete() function
> > +           //       exposed in base class for taking care
> > +           //       of this on appropriate time.
> >             boost::mutex::scoped_lock lock(_qMutex);
> >             waitIfNeeded(lock);
> >     }
> 
> If you wanted to revert the change, this won't do it, because we are
> still doing waitIfNeeded both in the main loop, and in each of the
> audio and video parseNextChunk's.

Didn't want a revert, just a sleep.
Note that waitIfNeeded is NOT being done in each of the audio 
and video parseNextChunk, unless something was really parsed.
Partial input frames won't push anything to buffers and thus
won't get to the waitIfNeeded.
I belive this was the problem you were originally encountering
(high CPU usage at end of parsing).

> There should be no need for this gnashSleep.  If we have our locks
> and semaphores set correctly, the system scheduler should do the job
> without being manually forced to switch tasks.

My tests here don't confirm that the scheduler is succeeding in that.

--strk;

  ()   Free GIS & Flash consultant/developer
  /\   http://strk.keybit.net/services.html



reply via email to

[Prev in Thread] Current Thread [Next in Thread]