为什么WaitForSingleObject会妨碍对话框初始化？ [英] Why does WaitForSingleObject get in the way of dialog initialisation?

问题描述

出于64位兼容性的目的，我将第三方DLL包装为32位基于单对话框的MFC应用程序。然后我生成该应用程序并等待它在我的主进程中完成，使用它生成的文件。



这一切都正常。为了使它以更加集成的方式运行，我传入了我的主窗口的类名，因此子应用程序可以找到它并将其用作对话框的父级。如果我单独运行子应用程序（使用正确的命令行），这也有效。



但是，当我从主应用程序生成子进程并且 WaitForSingleObject 从不显示对话框，就像它首先进入等待循环一样。我确实需要等待我的子应用程序完成，所以任何人都知道我怎么能正确地为它做父母？

For purposes of 64 bit compatibility, I've wrapped a third party DLL as a 32bit single-dialog-based MFC app. I then spawn that app and wait for it to finish in my main process, using the file that it produces.

This all works fine. To make it behave in a more integrated fashion I'm passing in the class name of my main window, so the sub-app can find it and use it as a parent for the dialog. This also works if I run the sub-app separately (with the correct command line).

However, when I spawn the child process from my main app and WaitForSingleObject the dialog is never displayed, like it got into the wait loop first. I do need to wait for my sub-app to finish, so anyone know how I can parent it properly?

推荐答案

我看不到你的代码，但谁告诉你你的 WaitForSingleObject 不应该妨碍你的执行。它阻止任何线程，无论它是什么。首先，看起来你不明白它的作用。没有任何等待循环。让我告诉你：试图在一个循环中等待一些东西，这被称为旋转等待，这是一种耻辱。有时你必须这样做，这不是你的错，但它肯定是由于你使用的一些软件甚至硬件的错误



现在，线程通过将其置于睡眠状态来阻止，没有任何循环。这意味着它被关闭（由系统抢占）并被标记为休眠，从未被调度回执行直到它被唤醒，这在几个条件下发生，首先是对象的信号状态，然后超时等等。重要的是，没有任何内容可读。操作系统以均匀的方式工作，然后唤醒进程，即删除睡眠状态并切换到此线程。



你需要计算你自己为什么你的对话（或其他）被阻止了。通常，简单的逻辑有帮助，但是存在复杂的多点死锁链的复杂情况;当你必须以一种基本的方式重新设计你的代码并严肃地简化线程时，通常就是这种情况。如果它是由于错误而发生的，那么这些错误很难被发现，因此代码重新设计是最可行的方法。

-SA

I cannot see your code, but who told you that your WaitForSingleObject should not get in the way of your execution. It blocks any thread, no matter what it is. First of all, it looks like you don't understand what it does. There is no any "wait loops". Let me tell you: the attempts to wait something in a loop, which is called "spin wait", is the shame. Sometimes you have to do it and this is not your fault, but then its certainly due to the fault of some software or even hardware you are using

Now, the thread is blocked by putting it in a sleep state, without any loops. It means that it is switched off (preempted by the system) and marked "sleeping", never scheduled back to execution until it is waken up, which is happened on several conditions, first of all, signaled state of the object, and then timeout, and other thing. Importantly, nothing reads the condition. The OS works in an even-oriented manner, and then it wakes up the process, that is, removes sleep state and switches to this thread.

You need to figure out yourself why your dialog (or anything else) is blocked. Usually, simple logic helps, but there are complex cases with complicated multiple-point deadlock chain; and usually this is the case when you have to redesign your code in a fundamental way and simplify threading seriously. If it happens as a result of a bug, such bugs can be extremely hard to detect, so code redesign is the most feasible approach.

—SA

所以似乎将对话框父设置为等待的应用程序窗口是问题，我可以理解。我通过从类名中找到父窗口并将窗口传递给对话框来实现我想要的目的 - 但不是 CDialog （因此没有设置父级）。然后我使用 CenterWindow 与父 CWnd 。

So it seems setting the dialog parent to the waiting app window was the problem, which I can kind of understand. I achieved what I wanted by finding the parent window from the class name, and passing the window to the dialog - but not to CDialog (so no parent is set). I then just used CenterWindow with the parent CWnd.

这篇关于为什么WaitForSingleObject会妨碍对话框初始化？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！