|
You are FRAKKIN' RIGHT! It was a typo, but now fixed it to something that cannot go wrong. 
It is a crappy thing, but it's life -^ Carlo Pallini
|
|
|
|
|
CPallini wrote: Rajesh R Subramanian wrote:
It cleans up its own mess, unless you set the m_bAutoDelete variable to TRUE before the thread starts.
Is quite the opposite, I suppose. Am I wrong?
Just to be clear:
If CWinThread::m_bAutoDelete is set to TRUE, the destructor closes the thread handle. To be able to wait on the thread handle from another thread m_bAutoDelete must be set to FALSE.
"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknown
|
|
|
|
|
I think Carlo was talking with regards to be able to manually 'delete' the CWinThread object, which can be done with the m_bAutoDelete member set to FALSE.
It is a crappy thing, but it's life -^ Carlo Pallini
|
|
|
|
|
Rajesh R Subramanian wrote: I think Carlo was talking with regards to be able to manually 'delete' the CWinThread object
I understood it differently.
I think he's talking about that your sentence can be interpreted as "if m_bAutoDelete is set to TRUE, CWinThread will not clean up its own mess".
You've got a way with words Rajesh. 
"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknown
|
|
|
|
|
Roger Stoltz wrote: I think he's talking about that your sentence can be interpreted as "if m_bAutoDelete is set to TRUE, CWinThread will not clean up its own mess".
It occurred to me as well, but I went through the whole conversation again and finally found out something that made sense. Now, let's hope Carlo doesn't come up to tell us he was actually talking about Pasta and Rosemary.
It is a crappy thing, but it's life -^ Carlo Pallini
|
|
|
|
|
Rajesh R Subramanian wrote: Carlo doesn't come up to tell us he was actually talking about Pasta and Rosemary.
Nope, you should know, I was actually talking about pizza 'napoli' and beer.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
If I recall well, that isn't the whole story, The CWinThread pointer is deleted too.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
CPallini wrote: If I recall well, that isn't the whole story, The CWinThread pointer is deleted too.
You recall correctly! 
There's a delete this; in the destructor as well that is executed if m_bAutoDelete is set to TRUE.
I omitted it for brevity since I considered the name of the variable m_bAutoDelete rather self-explanatory. 
But the only thing the OP need is to read Joe's article over and over again until it's understood. Really.
"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknown
|
|
|
|
|
Roger Stoltz wrote: But the only thing the OP need is to read Joe's article over and over again until it's understood. Really.
"Softly spoken magic spells".
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
The issues with what you've done are:
1. You haven't shown us what you're doing inside the 'run' function. (can you please rename it to something other than run, I'm just terrified looking at the context - CWinThread::Run() ... you get the picture)
2. Your WaitFor... call does not 'wait', it just performs a check on a thread which might be running or might be dead, and then attempts to delete something which (again) may have been already dead (you haven't set the m_bAutoDelete to TRUE).
You may first try to run a thread successfully, and then try using Events with WaitFor... functions. Simulate processing with Sleep(10) within a loop (for learning purposes) and then shut it down gracefully by setting an Event. You need not 'delete' the CWinThread object, like I said. Give that excellent article another read, and you will be all set. Post a reply, if you're stuck somewhere.
It is a crappy thing, but it's life -^ Carlo Pallini
|
|
|
|
|
1. Run is simple displaying function. which has nothing to do with CWinThread::Run().
Now it looks like below...
CWinThread * myWorkerThread;
myWorkerThread = AfxBeginThread(run, this);
myWorkerThread->m_bAutoDelete = TRUE;
UINT run(LPVOID pParam)
{
..........
............
// display the data
}
In ~Destructor()
{
DWORD result =WaitForSingleObject(myWorkerThread->m_hThread,0);
if(result == WAIT_OBJECT_0)
delete myWorkerThread;
}
2. In WaitFor... I have given time 0 as I require only to check the status of the thread.
|
|
|
|
|
mikert_2008 wrote:
CWinThread * myWorkerThread;
myWorkerThread = AfxBeginThread(run, this);
myWorkerThread->m_bAutoDelete = TRUE;
In all the confusion from the discussion earlier today you're partly forgiven, but consider the following for spawning the worker thread:
CWinThread* pThread;
pThread = AfxBeginThread( run, this, 0, 0, CREATE_SUSPENDED, NULL );
if( pThread )
{
pThread->m_bAutodelete = FALSE;
pThread->ResumeThread();
}
What kind of event stops the worker thread from running?
The way I interpret your destructor is that the thread does its job and then terminates by itself.
What does the thread do? Your comment "display the data" worries me since you should not touch the GUI from a worker thread in order to avoid deadlocks.
Probably you shouldn't be using multithreading at all for the problem you're trying to solve, since you seem to be doing thing sequentially and not in parallel.
Your destructor doesn't really make sense. There's also a race condition that in most cases would generate an exception when you're trying to free memory that has already been freed since you haven't set m_bAutoDelete to FALSE. You're mixing manual and automatic deletion of the CWinThread object.
You should also make sure all thread spawned by your program are terminated before allowing the program to exit. It's considered Best Practice because when you exit your program you don't have the power to do anything about it any longer.
The most harsh way the code that waits for the thread to exit could be like this:
if( pThread )
{
if( ::WaitForSingleObject( pThread->m_hThread, INFINITE ) == WAIT_OBJECT_0 )
{
delete pThread;
pThread = NULL;
}
}
You need to get back to the article and read it again as the above suggests that you haven't read it carefully enough and apparently have not understood it properly.
Believe me, I've suggested Joe's article to fellow programmers since he wrote it almost a decade ago. In my opinion it's the best article that can be found on the internet describing multithreading, especially together with MFC framework.
"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknown
|
|
|
|
|
mikert_2008 wrote: This I will put in the destructor of class (which starts the thread)...
You're starting a thread from within the destructor? 
"Old age is like a bank account. You withdraw later in life what you have deposited along the way." - Unknown
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
|
|
|
|
|
You need two CEvent objects, one representing the request from the primary thread to stop, and the other representing the acknowledgment from the secondary thread that it has stopped. When the primary thread responds to a stop request (e.g., Alt+F4, X, Cancel), it signals the first event and then waits for the second event. In the secondary thread, call WaitForSingleObject() on that event with 0 as the wait time. If it comes back as signaled, signal the other event.
"Old age is like a bank account. You withdraw later in life what you have deposited along the way." - Unknown
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
|
|
|
|
|
Hi There.
I am not able to use C# Managed DLL into my VC++ Application (DLL).
Below are the steps I am doing but with no success.
1. Copied C# DLL into the folder where all my lib files reside.
2. Included #using :GT:JPEGMaker.dll:LT: statement into stdafx.h file
3. After this I got an error message regarding CLR Support, so I enabled the same in project settings.
4. After this I got a linking error...
:GT: Greater Then Sign
:LT: Less Then Sign
Please provide details or Do I need to convert C# DLL into Native DLL?
Thanks
PanB
|
|
|
|
|
PankajB wrote: Please provide details or Do I need to convert C# DLL into Native DLL?
No, you need to re-post this in the correct forum[^] and then provide some detail, like what linker error you got...
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
|
|
|
|
|
Ohh Thanks. Yes thats a correct group to talk in...
|
|
|
|
|
I want to use Hindi in my multilingual application. So can anyone tell me that "Which one is the best font for Hindi language"?
thank you.
|
|
|
|
|
Please let me google that for you [^].
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
I have done that already.
|
|
|
|
|
Fixedsys 
|
|
|
|
|
There is no one 'best font' for any language. If you are writing an Unicode application, the Devnagari script would be displayed automatically (by default) with Mangal. You need not worry about fonts, if you are working on an Unicode aware application.
It is a crappy thing, but it's life -^ Carlo Pallini
|
|
|
|
|
When VC++ "LineTo" statement is called very often (say every 100 ms), it is using more resource and it is not getting released. If my application is running for longer period (say 2 hours), high usage of resource problem causing more RAM usage and memory is not getting released and growing continuously.
Sample code is given below (Please send your personal email id, so that I can email complete code)
//------------------------------------------------------------------
//Callback method creation (100 ms)
m_nEventID = timeSetEvent(100,0,GeneratePeriodicCall,DWORD(this),TIME_PERIODIC);
//callback method
void CALLBACK GeneratePeriodicCall(UINT uID, UINT UMsg, DWORD dwUser, DWORD dw1, DWORD dw2)
{
CTestAppView* pView = (CTestAppView*) dwUser;
//kill thread if active
if(g_hDrawChartThread != INVALID_HANDLE_VALUE)
{
DWORD dwExitCode =NULL;
DWORD dw = NULL;
GetExitCodeThread(g_hDrawChartThread, &dwExitCode);
if(dwExitCode == STILL_ACTIVE)
{
::CloseHandle(g_hDrawChartThread);
g_hDrawChartThread = NULL;
}
else
{
g_hDrawChartThread = NULL;
}
}
//create thread
g_hDrawChartThread = CreateThread(NULL,0,DrawChart,pView,0,0);
}
//Thread call
DWORD __stdcall DrawChart(LPVOID lParam)
{
CTestAppView* pView = (CTestAppView*)lParam;
CClientDC dc(pView);
int nSaveDC = dc.SaveDC();
long x = 0;
long y = 0;
for(long i = 0 ; i < 100000 ;i++)
{
dc.MoveTo(x,y);
//THIS LINE IS CAUSING SERIOUS RESOURCE LEAK
dc.LineTo(x + 1, y + 1);
x = x + 1;
y = y + 1;
}
dc.RestoreDC(nSaveDC);
return 0;
}
//------------------------------------------------------------------
Anyone can clarify me why "LineTo()" is not releasing resources & utilising more RAM. This RAM memory is not getting released until unless I close my VC++ application.
Any solution/hint, welcome.
Thanks in advance,
Madhu
|
|
|
|
|
I don't know exactly why you encounter a memory leak, but one think that is sure is that you are doing it the wrong way: you should never access your user interface from a separate thread (which is what you are doing here). This is not the way to do it. Instead, in a separate thread, you can add data in a std::vector (for instance) which is protected against multi-threading access and then you send a message to the UI to refresh itself. The UI will then (in the main thread) extract information from the vector and draw the additional points.
I don't know if this will fix your problem but this is something you'll have to fix or you'll encounter problems in the future.
|
|
|
|
|
I don't think LineTo() causes high usage of resource&RAM. You are exactly doing it in wrong way.
Firstly, you need to understand the callback function of a timer in VC can be re-called while previous call is not completed yet. Basically, each callback will create a thread.
Secondly, I don't understand why you create a thread in the callback function, which will lead to run many threads at the same time.
So i think running many threads at the same time causes your problem.
If you want to update you UI, you can set a timer or a thread in your UI class which gets data and draw them on UI periodically. Meanwhile, there is another thead to prepare those drawing data.
Welcome to www.softwaretree.net!
This website is generated completely by static html pages transforming technology.
You can find many excellent audio/video tools there!
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
