Re[4]: wxThread->Delete hangs, is there a work around?

by **vadim** » Fri, 02 Jul 2004 08:16:47 GMT



RF> Well, I tried it and it gave me less information than what I have
RF> provided before..   It exited with a first chance exception.  The spot
RF> which it exited was : 
RF> 
RF> return m_internal->WaitForTerminate(m_critsect, pRc, this);

 What is the value of m_internal? Has it been already deleted?

RF> Why does it need to Waitfortermination?

 I can't answer this otherwise than by telling you to read the code...

RF> One idea I had was to change a bool value inside the thread class.
RF> That way, in the worker thread loop, I would keep checking the bool
RF> value, and when it changed to true (for cancel) I could exit the
RF> thread.. 

 Well, this is exactly what TestDestroy() already does.

RF> Also, what does the term "This function can only be called from
RF> another thread context" mean ?

 It can't be called by the thread itself.

 Regards,
VZ


---------------------------------------------------------------------
To unsubscribe, e-mail:  XXXX@XXXXX.COM 
For additional commands, e-mail:  XXXX@XXXXX.COM

by **vadim** » Fri, 02 Jul 2004 08:20:36 GMT



RF> The problem?    The documentation doesn't say that you can't delete
RF> detachable threads...   

 I would have thought that this quote from wxThread docs:

	... all detached threads must be created on the heap because the
	thread will call delete this; upon termination...

would be enough. It's obviously incorrect to delete the same object twice!

RF> Well, I tried this, in fact early on, but what I didn't know was that
RF> when you put the bool inside the thread class and then try to change
RF> it from the parent by doing something like thread->stopthread=true; ,
RF> it caused the exceptions I was seeing -- the thread doesn't stop, and
RF> GUI locks up)..

 Certainly not because of a simple (and thread unsafe, it should be
noticed) assignment. There must have been something else.

RF> It works when you put the bool value in the Parent class..  It seems
RF> the thread can access the parent and change its values, but the parent
RF> CAN'T change the threads variables.

 This is totally wrong.

 Regards,
VZ


---------------------------------------------------------------------
To unsubscribe, e-mail:  XXXX@XXXXX.COM 
For additional commands, e-mail:  XXXX@XXXXX.COM

by **fox_no_spam-usenet001** » Fri, 02 Jul 2004 12:59:26 GMT






NO NO NO,  when I said delete, I mean wxThread::Delete(), not the heap
delete...


I found the problem though..  My bad on this, everything seems to be
working ok now..

I had a variable named "thread" in the function and that was same name
as the one in the class...  thus, it was a scope issue.. When I tried
wxThread::Delete(), it didn't have the proper address in it, thus the
error...  I didn't catch it because the same function that starts the
thread also stops it..  

My bad..

Thanks

Randall Fox



---------------------------------------------------------------------
To unsubscribe, e-mail:  XXXX@XXXXX.COM 
For additional commands, e-mail:  XXXX@XXXXX.COM

Re[4]: wxThread->Delete hangs, is there a work around?

Re[4]: wxThread->Delete hangs, is there a work around?

Jump to:

Next

Re[4]: wxThread->Delete hangs, is there a work around?

Re[4]: wxThread->Delete hangs, is there a work around?

Re: Re[4]: wxThread->Delete hangs, is there a work around?

Similar Threads:

Who is online