好像使用 用户界面线程 没什么好处,同样如果主线程(比如对话框的某个正在操作的成员阻塞)或 UI线程阻塞(对话框的某个正在操作的成员阻塞)也会影响到其他线程不能执行,只有到不在阻塞才能恢复。我查了资料好像是关于线程间对话框调度原因。既然是这样,那还用UI线程干嘛,工作者线程同样可以处理这样类型的问题(好像)请高手门帮我揭开心底的谜团,迷糊主线程
CXXXDlg OnXXXX()
{
     //耗时,阻塞
}

UI线程
CUIDlg OnXXXX()
{
     //耗时,阻塞
}

解决方案 »

  1.   

    当好像又有点不一样,按常理来说,如果一个UI线程的界面阻塞,其他线程是不会受影响的(这是我最初的理解)
    但UI线程关于到界面(控件)阻塞,其他线程也阻塞了,根本无法继续走下去,如我举得例子
      

  2.   

    对Win32来说,它最基本的只是一个API:CreateThread,在这个线程中干什么,是弹出一窗口还是默默的计算是你自己的事.
    工作者线程一般没有消息队列,可以自己强制加入,
    UI线程有窗口,自己有消息队列。
    我想分开了说只是为了让有窗口和无窗口的界面达到一些规范和共性。
      

  3.   

    谁说的UIThread阻塞,会影响其他Thread的再说UIThread 一般要么处理消息,要么是由窗口的,一般情况我们是不会让你其阻塞得去执行一个
    长时间的任务的,如果有这样的操作也创建一个工作Thread去完成
      

  4.   

    ui线程一个就够了,就是主界面,我一直不理解为什么还要有别的ui线程
      

  5.   

    所谓UI线程就是拥有消息循环的线程,如果两个线程中的界面部分几乎都是独立逻辑的话用多个UI线程未尝不可,但这种应用相对来说的确是很少的
    UI线程与普通工作线程的最大差异就在于他们的同步处理通常使用 SendMessage 和 PostMessage 来完成,而非通常的互斥和同步内核对象
    从逻辑上来说,UI线程和普通线程并没有本质差异