1

My Windows application has a tabbed interface. Every tab will render some UI stuff. As everyone knows, if I do a very time consuming for-loop in the main thread without let other to process any Windows messages, the application will be frozen. During the frozen period, I cannot switch tabs.

I was inspired by the multiple process architecture of Google Chrome. I try to use SetParent to embed a process into another process. To be more specific: Process A is the master. It can create unlimited worker processes. Every worker process has its own message loop. If process B is frozen, process A and any other worker processes should not be frozen.

Actually I am wrong: If I click a button worker process B to do a lot of UI stuff in main thread without a break, not only the UI of process B but also the UI of process A will be blocked, until my test code ends.

Can somebody share some lights to me?

Community
  • 1
  • 1
stanleyxu2005
  • 8,081
  • 14
  • 59
  • 94

1 Answers1

7

What you are attempting to do is, er, tricky to get right. I suggest that you start by reading Raymond Chen's article: Is it legal to call have a cross-process parent/child or owner/owned window relationship

Creating a cross-thread parent/child or owner/owned window relationship implicitly attaches the input queues of the threads which those windows belong to, and this attachment is transitive: If one of those queues is attached to a third queue, then all three queues are attached to each other. More generally, queues of all windows related by a chain of parent/child or owner/owned or shared-thread relationships are attached to each other.

This is exactly the scenario that you describe. And the fusing of all the message queues is to be expected. The fact that you have multiple processes doesn't change the fact that you must not block UI threads.

So I think that your program design is flawed. You are adding an epic amount of complexity, with no reward. The benefits of a multi-process architecture are security and isolation. You don't change anything with regards to blocking UI threads. The only way to solve your problem is to put the long running task on a non-UI thread. My strong advice is to return to a single process design.

sergiol
  • 4,122
  • 4
  • 47
  • 81
David Heffernan
  • 601,492
  • 42
  • 1,072
  • 1,490
  • Single process design does not solve my issue. I want to render different UI stuff in tabs. Actually I do have long running UI tasks. If I use single process and one tab freezes, the whole UI freezes. – stanleyxu2005 Mar 02 '14 at 18:37
  • 1
    Single process solves it fine. Put the long running task into worker thread. You just aren't doing it right. I cannot say it any more clearly than this: don't block UI threads. – David Heffernan Mar 02 '14 at 18:38
  • For example, I embed a TWebBrowser into the application. The browser loads a html, which will run a long running javascript. Before the javascript ends, the UI will be frozen. I cannot control javascript of a browser control to be run in a thread. – stanleyxu2005 Mar 02 '14 at 18:40
  • I think I answered the question you asked right? How you design your app is up to you, but I would make sure not to block the UI thread. – David Heffernan Mar 02 '14 at 18:50
  • I agree with you that `do not put long running tasks into the UI thread`. But my question is not about a design issue, but a technique issue. I tried to follow Google Chrome to minimize the affect of UI thread frozen, but I have some issues. Google Chrome uses multiple process. If some UI is frozen, the main UI is not frozen. I want to archive the same result. This is my goal. – stanleyxu2005 Mar 02 '14 at 18:58
  • 1
    In Chrome they don't block UI threads. The question you asked was why blocking one UI thread, blocks them all. And the answer, as explained in Raymond's article, is that all your UI threads are attached. – David Heffernan Mar 02 '14 at 19:01
  • 1
    FYI, recent versions of IE also use a multi-process approach for its tabs. It is not just to isolate the UIs, but to isolate memory and resources as well. If a given process is compromised by malicious code, only that one tab is compromised, not the entire browser as a whole. – Remy Lebeau Mar 02 '14 at 19:43
  • @DavidHeffernan, I revised my question. Thanks for quick response with very helpful information. – stanleyxu2005 Mar 03 '14 at 02:59
  • I think you are confusing the answer to the question that you asked with the solution to your problem. You asked about the attaching of all your input queues and I answered that. In any case the solution to your problem is as I have said many times, that you must not block UI threads. I've got nothing more to say. I honestly believe that I answered the question that you asked. I hope you don't edit the question to change the question. – David Heffernan Mar 03 '14 at 07:04
  • @DavidHeffernan I reverted to the original question. Your answer is very informative. I will raise another question to my new question. – stanleyxu2005 Mar 03 '14 at 08:18