Hi Eljay,
Thanks for sticking with my problem and all the 'nice' suggestions.
We have a very large system where an 'execution' thread is taking care of
running, the main thread monitors it and is required to have the ability to
stop
the execution at any time. Use a separate process is a solution but the two
threads
share a lot of data and communications with other processes/CPUs.
I'm not sure how active you are involved with the GCC development, is there
a
technical problem preventing this from happening or it's just nobody is
considering
doing it? We can consider other compilers but we really like to use GCC
because
then we can pretty much use the 'same' compiler for different platforms.
Thanks.
Yufeng
Eljay Love-Jensen
<eljay@xxxxxxxxx>
To
09/16/2004 04:04 Yufeng_Xiong@xxxxxxx
PM cc
gcc-help@xxxxxxxxxxx
Subject
Re: Question on
pthread_cancel/pthread_exit and
thread stack unwind
Hi Yufeng,
One alternative is to make sure all items are created / destructed in the
main thread then handed over to the spawned threads, keeping track of which
object is under the domain of which TID. Use reference counting, and post
their imminent demise to a reaper list which the main thread acts
upon. Any TID that is noted causes the main thread to go through it's
outstanding object list to put all those items on the reap list -- note
that reference counts may let them stay around for a few cycles until the
things referring to them are destructed. Disallow stack based objects in
threads.
May not be doable depending on all your developers and the third party code
you use.
Or, you could try fixing those issues of pthread_cancel / pthread_exit
abuse with QA and apoplectical management.
Or, try bribing the developers with cookies and donuts. If that fails, use
thumbscrews.
Or, if you want proper garbage collecting in a multithreaded environment,
use Java. (Multithreading is a "bolt on" for C and
C++. Unfortunately. It's not going become part of the language proper any
time soon.)
--Eljay
