{"id":14493,"date":"2010-03-25T07:00:00","date_gmt":"2010-03-25T07:00:00","guid":{"rendered":"https:\/\/blogs.msdn.microsoft.com\/oldnewthing\/2010\/03\/25\/waitforinputidle-should-really-be-called-waitforprocessstartupcomplete\/"},"modified":"2010-03-25T07:00:00","modified_gmt":"2010-03-25T07:00:00","slug":"waitforinputidle-should-really-be-called-waitforprocessstartupcomplete","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/oldnewthing\/20100325-00\/?p=14493","title":{"rendered":"WaitForInputIdle should really be called WaitForProcessStartupComplete"},"content":{"rendered":"<p>The <code>WaitForInputIdle<\/code> function waits for a process to finish its initialization, which is determined when it reaches a state where it is just sitting around waiting for messages.\n The documentation for <code>WaitForInputIdle<\/code> doesn&#8217;t even get around to the initialization part until the <b>Remarks<\/b> section. If all you read is the one-sentence summary, <i>Waits until the specified process is waiting for user input with no input pending, or until the time-out interval has elapsed<\/i>, it would not be unreasonable for you to conclude that a process goes into and out of the <i>input idle<\/i> state each time it processes a message. But no, it&#8217;s a one-time transition.\n If you call <code>WaitForInputIdle<\/code> on a process which had previously gone input idle, but is now busy and not processing pending input messages, the function will still return immediately, because <code>WaitForInputIdle<\/code> only checks whether the process has gone input idle <i>at all<\/i> and not whether it is input idle <i>right now<\/i>.\n As the <b>Remarks<\/b> section notes, the purpose of the <code>WaitForInputIdle<\/code> function is for a process to determine whether another process (which is recently launched) has reached a state where it is okay to send that process messages. This is important to know when the form of communication between two processes is a message-based mechanism, and the two processes otherwise have no real way of knowing what the other is doing. (If the two processes had been written by the same author, then you could come up with some more expressive interface for the two to communicate through, one which avoids the need for one process to guess when the other one is ready.) The specific scenario that <code>WaitForInputIdle<\/code> was created to address is <a href=\"http:\/\/blogs.msdn.com\/oldnewthing\/archive\/2007\/02\/26\/1763683.aspx\"> DDE<\/a>.\n Back in the old 16-bit days, you didn&#8217;t need a <code>WaitForInputIdle<\/code> function, because scheduling was co-operative. You know that the other process was sitting idle, because if it were busy, your code wouldn&#8217;t be running in the first place. It&#8217;s like waiting for the <a href=\"http:\/\/www.acaciart.com\/stories\/archive6.html\"> talking stick<\/a> to be handed to you so that you can ask the question, &#8220;Are you ready to give up the talking stick?&#8221; The <code>WaitForInputIdle<\/code> function assisted in the porting of these 16-bit applications by allowing a process to wait and simulate the &#8220;Wait for the other person to stop talking&#8221; operation which had previously been implicit in a co-operative system.\n What would it mean for <code>WaitForInputIdle<\/code> to wait on a program that has already completed its initialization, when the program has multiple threads? Suppose one thread is sitting around waiting for messages, but another is busy and still has unprocessed input messages. Would a call to this <code>WaitForInputIdleAgain<\/code> function wait, or should it return immediately? According to the description, it would return immediately, because there is a thread in the process which is &#8220;waiting for user input with no input pending.&#8221; So even if <code>WaitForInputIdle<\/code> worked like this imaginary <code>WaitForInputIdleAgain<\/code> function, it still wouldn&#8217;t help you, because it wouldn&#8217;t actually wait in cases where you probably wanted it to.<\/p>\n<p> Actually, the above analysis applies to <code>WaitForInputIdle<\/code> as well; <a href=\"http:\/\/blogs.msdn.com\/oldnewthing\/archive\/2010\/03\/26\/9985422.aspx\"> we&#8217;ll pick up this discussion next time<\/a>. <\/p>\n","protected":false},"excerpt":{"rendered":"<p>The WaitForInputIdle function waits for a process to finish its initialization, which is determined when it reaches a state where it is just sitting around waiting for messages. The documentation for WaitForInputIdle doesn&#8217;t even get around to the initialization part until the Remarks section. If all you read is the one-sentence summary, Waits until the [&hellip;]<\/p>\n","protected":false},"author":1069,"featured_media":111744,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[1],"tags":[25],"class_list":["post-14493","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-oldnewthing","tag-code"],"acf":[],"blog_post_summary":"<p>The WaitForInputIdle function waits for a process to finish its initialization, which is determined when it reaches a state where it is just sitting around waiting for messages. The documentation for WaitForInputIdle doesn&#8217;t even get around to the initialization part until the Remarks section. If all you read is the one-sentence summary, Waits until the [&hellip;]<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/14493","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/users\/1069"}],"replies":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/comments?post=14493"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/14493\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/media\/111744"}],"wp:attachment":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/media?parent=14493"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/categories?post=14493"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/tags?post=14493"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}