From 9e88754b26413976b613da9d8f9b0c86df948cac Mon Sep 17 00:00:00 2001 From: Chris Tallon Date: Sun, 1 Jun 2008 18:53:57 +0000 Subject: [PATCH] Code cleaning --- boxstack.cc | 24 -------------------- timers.h | 58 +++++++++++++++++++++++++++-------------------- vaudioselector.cc | 5 +++- vchannellist.cc | 20 ++++------------ vconnect.cc | 3 +-- vdr.cc | 7 ------ vdr.h | 1 - vradiorec.cc | 8 ------- vvideorec.cc | 8 ------- wprogressbar.cc | 2 -- 10 files changed, 43 insertions(+), 93 deletions(-) diff --git a/boxstack.cc b/boxstack.cc index 2d33758..e4c620f 100644 --- a/boxstack.cc +++ b/boxstack.cc @@ -18,30 +18,6 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA. */ - -/* - -#ifndef WIN32 - pthread_mutex_lock(&boxLock); -#else - WaitForSingleObject(boxLock, INFINITE); -#endif - - -#ifndef WIN32 - pthread_mutex_unlock(&boxLock); -#else - ReleaseMutex(boxLock); -#endif - - - - -*/ - - - - #include "boxstack.h" #include "command.h" diff --git a/timers.h b/timers.h index d554aa8..34ab673 100755 --- a/timers.h +++ b/timers.h @@ -12,30 +12,40 @@ FYI -Timers ... deprecated. Maybe. - -This whole thing will be replaced with a timed-message idea. It will be possible -to send yourself (or whoever) a message with a delay, or delivery time. The message -will be handed to Command as usual, but command will do the right thing. The messages -will be delivered to the recipient _with the gui mutex locked_, meaning updates can -be done there and then in the message handler. - -Good points: -* Cuts down on code lines -* Most (all?) timercall()s eventually send a message to command in order to - do something within The Big Mutex. This makes it easier and simpler code wise -* Gets rid of Timers. -* Hopefully gets rid of most postMessageFromOuterSpace calls - -Bad points: -* Timers become gui only features. Solve this with a MessageReceiver interface and - have command deliver messages straight to the recipients rather than through BoxStack. -* Timer delivery accuracy becomes dependant on everything that uses The Big Mutex. - It will become more important to not block The Big Mutex. -* Cancelling timers... hmm - -If you have any comments about the new design, like, "It's just as flawed as the old one", -then I'd appreciate hearing it before I start writing it all :) +Fixed: + +The main problem was that timers only seemed to launch messages which went into The Big Mutex. +This has been fixed a different way by implementing locking in BoxStack - meaning timercalls +can now draw and update their displays without locking The Big Mutex. Problem solved. I think +the whole program might move more towards classes keeping more mutexes and rely less on The +Big Mutex. + + + +> Timers ... deprecated. Maybe. + +> This whole thing will be replaced with a timed-message idea. It will be possible +> to send yourself (or whoever) a message with a delay, or delivery time. The message +> will be handed to Command as usual, but command will do the right thing. The messages +> will be delivered to the recipient _with the gui mutex locked_, meaning updates can +> be done there and then in the message handler. + +> Good points: +> * Cuts down on code lines +> * Most (all?) timercall()s eventually send a message to command in order to +> do something within The Big Mutex. This makes it easier and simpler code wise +> * Gets rid of Timers. +> * Hopefully gets rid of most postMessageFromOuterSpace calls + +> Bad points: +> * Timers become gui only features. Solve this with a MessageReceiver interface and +> have command deliver messages straight to the recipients rather than through BoxStack. +> * Timer delivery accuracy becomes dependant on everything that uses The Big Mutex. +> It will become more important to not block The Big Mutex. +> * Cancelling timers... hmm + +> If you have any comments about the new design, like, "It's just as flawed as the old one", +> then I'd appreciate hearing it before I start writing it all :) */ diff --git a/vaudioselector.cc b/vaudioselector.cc index 97306ff..3315d73 100644 --- a/vaudioselector.cc +++ b/vaudioselector.cc @@ -249,7 +249,10 @@ VAudioSelector::~VAudioSelector() int audioChannelListSize = acl.size(); for(int i = 0; i < audioChannelListSize; i++) { - delete acl[i]; // FIXME memory leak - nobody is deleting audio channel name? + // FIXME memory leak - nobody is deleting audio channel name? // try: + delete[] acl[i]->name; + Log::getInstance()->log("VAudioSelector", Log::DEBUG, "Deleted char[] on close"); + delete acl[i]; } acl.clear(); diff --git a/vchannellist.cc b/vchannellist.cc index d0d0aa4..a663fcc 100644 --- a/vchannellist.cc +++ b/vchannellist.cc @@ -219,22 +219,10 @@ int VChannelList::handleCommand(int command) if (chanList) chan = (Channel*)sl.getCurrentOptionData(); if (chan == NULL) return 2; -// if (chan->type == VDR::VIDEO) -// { - VVideoLiveTV* v = new VVideoLiveTV(chanList, chan->number, this); - boxstack->add(v); - v->go(); -/* - } - else - { - VVideoLive* v = new VVideoLive(chanList, chan->type, this); - v->draw(); - boxstack->add(v); - boxstack->update(v); - v->channelChange(VVideoLive::NUMBER, chan->number); - } -*/ + VVideoLiveTV* v = new VVideoLiveTV(chanList, chan->number, this); + boxstack->add(v); + v->go(); + return 2; } case Remote::BACK: diff --git a/vconnect.cc b/vconnect.cc index 8ad6f7d..9666156 100644 --- a/vconnect.cc +++ b/vconnect.cc @@ -120,8 +120,7 @@ void VConnect::threadMethod() selectedServer = -1; VServerSelect* vs = new VServerSelect(servers, this); vs->draw(); - boxstack->add(vs); // FIXME - do this better - perhaps post message to Command - // Otherwise it will be using BoxStack without the Command mutex locked + boxstack->add(vs); boxstack->update(vs); threadLock(); diff --git a/vdr.cc b/vdr.cc index e612c9d..57ef492 100644 --- a/vdr.cc +++ b/vdr.cc @@ -689,13 +689,6 @@ ChannelList* VDR::getChannelsList(ULONG type) return chanList; } - -int VDR::streamChannel(ULONG number) -{ - // FIXME radio - return 0; -} - int VDR::streamChannel(ULONG number, StreamReceiver* tstreamReceiver) { VDR_RequestPacket vrp; diff --git a/vdr.h b/vdr.h index 6c75dc4..a9eefe0 100644 --- a/vdr.h +++ b/vdr.h @@ -166,7 +166,6 @@ class VDR : public Thread_TYPE, public EventDispatcher int deleteTimer(RecTimer* delTimer); ChannelList* getChannelsList(ULONG type); int streamChannel(ULONG number, StreamReceiver*); - int streamChannel(ULONG number); void getChannelPids(Channel* channel); UCHAR* getBlock(ULLONG position, UINT maxAmount, UINT* amountReceived); //get image blocks separate - we can do this in parallel diff --git a/vradiorec.cc b/vradiorec.cc index a028d77..f0d53cf 100644 --- a/vradiorec.cc +++ b/vradiorec.cc @@ -317,15 +317,7 @@ void VRadioRec::stopPlay() { Log::getInstance()->log("VRadioRec", Log::DEBUG, "Pre stopPlay"); - // FIXME work out a better soln for this - // Fix a problem to do with thread sync here - // because the bar gets a timer every 0.2s and it seems to take up to 0.1s, - // (or maybe just the wrong thread being selected?) for the main loop to lock and process - // the video stop message it is possible for a bar message to stack up after a stop message - // when the bar message is finally processed the prog crashes because this is deleted by then removeBar(); - // - player->stop(); vdr->stopStreaming(); delete player; diff --git a/vvideorec.cc b/vvideorec.cc index 909a35f..f2ee7c0 100644 --- a/vvideorec.cc +++ b/vvideorec.cc @@ -531,15 +531,7 @@ void VVideoRec::stopPlay() { Log::getInstance()->log("VVideoRec", Log::DEBUG, "Pre stopPlay"); - // FIXME work out a better soln for this - // Fix a problem to do with thread sync here - // because the bar gets a timer every 0.2s and it seems to take up to 0.1s, - // (or maybe just the wrong thread being selected?) for the main loop to lock and process - // the video stop message it is possible for a bar message to stack up after a stop message - // when the bar message is finally processed the prog crashes because this is deleted by then removeBar(); - // - player->stop(); vdr->stopStreaming(); delete player; diff --git a/wprogressbar.cc b/wprogressbar.cc index d61daa0..b025a88 100644 --- a/wprogressbar.cc +++ b/wprogressbar.cc @@ -42,8 +42,6 @@ void WProgressBar::draw() if (area.w < 5) return; if (area.h < 5) return; - printf("progress bar: %u\n", percent); - // Hmm, can't draw two boxes because should not paint on areas // not needing it - this class does not know the background colour -- 2.39.2