如果可以分成小段时间的操作,那自然是很好办了,问题是这个操作不能分开:(
等的方法倒也有用的,NAV的那个LiveUpdate就是这么搞的,我点了中止都要等好半天,但我不喜欢这种效果

解决方案 »

  1.   

    本来我想用try{}finally{}的,一用才知道,这个东西在有析构函数的时候用不了,真是郁闷
      

  2.   

    TerminateThread虽然不建议使用,但它并不会导致类的无法正常析构,真的。
      

  3.   

    TerminateThread在关闭线程后,线程资源不会被释放,直到调用进程被关闭。这样的话,如果你的程序带有那种后台性质,时间一长,肯定会出问题。另外,工作线程中创建的类如果线程是非正常退出的话,那些类确实无法正常析够,我的程序就是因为这个原因造成内存泄漏,害得我都不敢用CString了:(
      

  4.   

    不知能否在你的线程中引入 Event 实现!
      

  5.   

    To:zhq2000
    引入Event当然可以保证资源的释放,但是如果线程需要比较长时间执行完的话(比如里面调用了一个函数,而这个函数需要很长时间),可能会有比较长时间的延时,我的意思就是说立即结束这个线程,同时保证线程所占用资源的正常释放。
      

  6.   

    CString是垃圾,真的,用的多了绝对影响资源。
    但是我为什么这么爱用....因为我懒
      

  7.   

    是啊,那个CString用这确是挺方便,+总比strcat少打几个字吧,再说我打字很慢,所以常用CString
      

  8.   

    在进程退出时 肯定是可以保证释放属于该进程的资源.要是长时间不返回的函数,好象是有点难办啊.
    在这种情况下,是否要考虑 用工作者线程 是否合理的问题.
    如果实现一个 类似COM里面的那种 报文队列线程,PostQuitMessage是否可以实现----具体我有些忘了,好象也是要等消息队列处理到该消息才退出,如果是这样的话,也不能满足要求.我还是听听吧.
      

  9.   

    所以,关键问题还是在函数长时间不返回那儿----要想办法让该函数 隔一定时间放弃一次CPU处理时间.
      

  10.   

    那就不要在线程里申请资源嘛,先在某个地方定义好足够的C++对象,以及可能用的资源,
    再作为参数传给线程,这样不就爱什么时候杀就什么时候杀了嘛,杀完了再释放相应资源。
    我一般是这样干的。不过好久没有写vc多线程程序,一下没有想起来。
      

  11.   

    GUI线程是可以接收消息,但那是单线程,当当正在处理数据时,应该是不会再去处理消息队列中消息的,这样结果还是和工作线程一样了。
    我想能不能让线程函数在需要的时候停止正在处理的数据,直接跳到结尾处。简直废话:(
      

  12.   

    GUI线程是可以接收消息,但那是单线程,当正在处理数据时,应该是不会再去处理消息队列中消息的,这样结果还是和工作线程一样了。
    我想能不能让线程函数在需要的时候停止正在处理的数据,直接跳到结尾处。简直废话:(
      

  13.   

    To:vcbear
    但问题是如果线程调用的函数中要用到C++对象呢?
      

  14.   

    对呀,可是你的c++变量不是在线程里定义的呀,你可以在别的地方得到这个c++对象
    调用它的释放函数。比如
    Struct _A
    {
      //Define C++ Obj here
       C++Obj  Obj;
    }A//main  class
    A m_A;
    m_A.Obj.Create;
    AfxBeginThread(...&m_A);//In thread use m_A //in Main Class
    TerminateThread
    m_A.Obj.Release;
      

  15.   

    比如这个样子:我的线程中用到了一个类的成员函数FuncTest,在FuncTest中申明了一个类,这种类是无法正常析构的。
    另外,看到AfxBeginThread,我又想起一件事。开始我的程序就是用AfxBeginThread,但发现用这个东西有些问题,当线程正在执行时,退出程序,在退出程序前,我用TerminateThread中断线程,但程序结束后,我发现居然有一个CWinThread对象泄漏了。不用AfxBeginThread,改成_beginthreadex就可以了。
      

  16.   

    当然了,你用AfxBeginThread的时候,创建并返回了一个CWinThread对象指针。
    你应该用一个变量把这个指针储存以待释放。这个问题的解决方案就是:如果你真的很在乎线程里资源泄露的问题,而不能保证,
    那么,你就不要在线程以及线程范围的代码里申请其他地方无法释放的资源。
      

  17.   

    唉呀!笨了!那个指针我保存了,但是只用TerminateThread中断线程,没有delete,呵呵……
      

  18.   

    Jeffrey Richter在"MSJ March, 1996"的Q&A:Win32里对这个问题做了详尽的阐述,并提供了一个很巧妙但并不完美的解决办法。我简述如下:
    TerminateThread的主要缺点有:
    1,线程栈不会被释放。因为这时可能有别的线程正在访问栈里的内容,TerminateThread如果把栈释放,会引起
    访问冲突。当然这个栈在程序结束时会被释放掉。这是所谓的资源泄漏。
    2,有些DLL需要处理DLL_THREAD_DETACH事件(例如MSVCRT40.DLL,VC的C运行时库),而TerminateThread不会发送这一事件,这会造成一些问题。
    3,可能引起程序死锁。试想,如果线程在调用EnterCriticalSection后被Terminate了,这就可能会挂起其他线程。Jeffrey的方法可以解决前两个问题。他的基本思路是让目标线程产生一个异常,通过异常展开,系统会为所有局部C++对象调用析构函数,然后退出线程,
    由于是线程自己退出,线程栈会被释放,所有DLL也会收到DLL_THREAD_DETACH通知。但是无法解决潜在的死锁问题。
    让目标线程产生一个异常很简单,只要用GetThreadContext然后SetThreadContext
    把eip改到自己的一段代码,然后调用RaiseException即可。
      

  19.   


    白菜你可以多看看msdn网站上Jeffrey 的文章(好象可以搜索到)。这个路子我看过的。
    但是没有singlerace理解翻译的清楚,也没有实验过。
      

  20.   

    最好的办法尽量避免执行操作时间长又不易中断的代码,
    多加一些同步代码,每隔一段时间就判断一下是否退出,并附上清理代码。
    TerminateThread不是好办法,但是最有效的也是唯一的。
      

  21.   

    如果实在没有什么好方法的话有EndDialog()吧,什么问题都解决了。