Message loop issue using SetParent to embed window into external process

Question

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?

Answer 1

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.