zoukankan      html  css  js  c++  java
  • GetWindowText 卡死的一种可能的原因

    最近一个项目中碰到GetWindowText经常卡死的问题,这个项目有多个线程,检查代码发现发生死锁的是一个数据线程和一个UI线程。

    示意图大致如下(data thread和UI thread在同一个进程中):

    无标题

    1,data thread Lock();

    2,data thread GetWindowText 会SendMessage(WM_GETTEXT) 给 UI window;

    3,UI thread message loop , processing WM_X,在处理messagex的过程中Lock(),所以处于WM_X之后的WM_GETTEXT消息无法被相应,以致于两线程互相死锁。

    所以看似是GetWindowText死锁,实际上是处理消息过程中发生死锁。

    最后的解决方法是不对本进程进行GetWindowText,GetWindowText其他进程的窗口不是发送WM_GETTEXT消息,而是去某个特定地区取出来,见MSDN:

    If the target window is owned by the current process, GetWindowText causes a WM_GETTEXT message to be sent to the specified window or control. If the target window is owned by another process and has a caption, GetWindowText retrieves the window caption text. If the window does not have a caption, the return value is a null string. This behavior is by design. It allows applications to call GetWindowText without becoming unresponsive if the process that owns the target window is not responding. However, if the target window is not responding and it belongs to the calling application, GetWindowText will cause the calling application to become unresponsive.

    To retrieve the text of a control in another process, send a WM_GETTEXT message directly instead of calling GetWindowText.

    这个问题与通常的死锁不同,一般的死锁是在于代码逻辑上的死锁,它的死锁在于SendMessage是同步的,锁发生的原因是消息处理的先后顺序。

    另外可参考:

    http://zhanyonhu.blog.163.com/blog/static/16186044200810187281835/

    这个链接中也差不多是相同的原因:

    在窗口的Msg process函数中给本窗口SendMessage,导致当前message处理过程在等待下一个message的处理结果,结果无意外,发生死锁!

  • 相关阅读:
    ES学习(十)
    ES学习(九)
    ES学习(八)
    ES学习(七)--documentAPI
    ES学习(六)--shard和replica机制
    ES学习(四)--嵌套聚合、下钻分析、聚合分析
    uniapp中常见的请求方法封装 --来之插件市场(全局方法封装(请求/正则/URI)
    工具/插件
    express中文件的上传 multer
    express中开发常用
  • 原文地址:https://www.cnblogs.com/xylc/p/3552467.html
Copyright © 2011-2022 走看看