Qt-based multi-process management method and device
By initializing the cross-process communication component in the main function and creating independent event loops in the main and child processes, the UI conflict problem caused by multiple main windows running in the same process in the Qt development framework is solved, realizing cross-platform multi-process management and improving UI response speed and system stability.
Patent Information
- Application Number
- CN202511551053.7
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-10-28
- Publication Date
- 2026-02-13
AI Technical Summary
In existing Qt-based development frameworks, multiple main windows running in the same process can easily lead to event loop conflicts, UI lag, and display disorder. In particular, repeated instantiation of QApplication in the Python environment can cause program abnormalities, and there is a lack of independent management solutions under the multi-process mechanism.
By initializing the cross-process communication component in the main function and creating independent event loops in the main process and child process respectively, communication is achieved by using signal and slot functions in combination with a global cross-process class, ensuring the decoupling and reliability of the main process and child process, and using a multi-process management method to run multiple QMainWindow independently.
It enables the independent operation and management of multiple main windows across platforms, improves the smoothness of interface response, reduces the risk of resource contention, ensures the stability and reliability of the system, and supports complex UI layouts and diverse needs.
Smart Images

Figure CN121523927A_ABST
Abstract
Description
TECHNICAL FIELD
[0001] The present application belongs to the technical field of computer multi-process management, and more particularly relates to a Qt-based multi-process management method and device. BACKGROUND
[0002] Existing graphical interface software usually runs in a single-process mode. In a Qt-based development framework, a unique QApplication instance must be created within a process, and a QMainWindow main window must be loaded in the instance to enter an event loop to respond to user operations. However, when the software needs to run multiple main windows simultaneously, the prior art often creates multiple QMainWindow instances in the same process, which can cause conflicts in the event loop and even cause interface lag or display disorder. In particular, when using the PyQt5 library in a Python environment, repeated instantiation of QApplication in the same process will directly cause program exceptions.
[0003] In application scenarios such as visual displacement monitoring that require real-time display and processing, the main process not only needs to bear the monitoring logic and parameter management, but also needs to support independent display of multiple chart windows. The prior art lacks a solution that can achieve independent running and management of multiple main windows in a single software project through a multi-process mechanism, and cannot simultaneously consider the smoothness of interface interaction, the reliability of inter-process communication, and the consistency of cross-platform operation.
[0004] The prior art disclosed in Patent No. CN114356435A proposes a Qt interface integration method and device, which manages multiple window layouts through a configuration table and RPC. However, it lacks isolation management of sub-processes, which can easily cause QApplication instance conflicts, program crashes, or interface display abnormalities. SUMMARY
[0005] To overcome the problem that existing graphical interface software cannot achieve independent running and management of multiple main windows in a single software project through a multi-process mechanism, the present application provides a Qt-based multi-process management method and device.
[0006] The primary object of the present application is to solve the above technical problems. The technical solution of the present application is as follows: The first aspect of the present application provides a Qt-based multi-process management method, comprising the following steps: Initializing a main function and a cross-process communication component, and executing the main function; Passing the cross-process communication component as a parameter into a sub-process creation process, creating a chart management sub-process, initializing the sub-process and executing it, and making the sub-process enter a cross-process communication waiting state; The cross-process communication component is passed as a parameter to the main process creation process, the main process is initialized and executed, and communication between the main process and child processes is achieved by using signal and slot functions in combination with a global cross-process class. If the user closes the modal display of the main process, release resources and exit safely.
[0007] Furthermore, the main function is initialized only once, and an entry protection is set at the beginning of the application's main function. The initialization logic of the main process is executed only when the program is run as the main process entry point.
[0008] Furthermore, the initialization of the inter-process communication component involves defining and instantiating a global inter-process class, and using the instantiated object as a parameter for inter-process communication. The global inter-process class includes a mutex lock, a message queue, and events.
[0009] Furthermore, the method for creating a chart management subprocess is through the multiprocessing.Process method.
[0010] Furthermore, the method for initializing and executing the child process involves creating a QApplication instance of the child process and using the exec_() method to modally execute the child process's main loop. The child process's main loop includes the following steps: Waiting for the main process's work instruction message; Upon receiving a work instruction message, create a QtChart chart class, instantiate the chart class, and implement the child process chart interface functionality within the instance; The non-modal display method show() of the chart class and the modal display method exec_() of the child process QApplication are called, blocking and waiting for the user to finish the operation and close the main chart window; After the user closes the main chart window, they wait for the next main process work instruction message.
[0011] Furthermore, after creating a QApplication instance, a timer is created and started. If the child process does not receive a work task from the main process within t milliseconds, the timer triggers and exits the child process's main loop, entering a low-power standby state. It then listens for and waits for the main process to send a work instruction to wake up the child process and re-enter the child process's main loop. If the child process receives a work task from the main process within t milliseconds, the timer is canceled.
[0012] Further, the main process is initialized and executed, including the following steps: Initialize the main process QApplication instance, QDialog instance, and database and shared memory parameters; Instantiate the main interface class, and pass the QDialog instance, database and shared memory parameters and global cross-process class as parameters to the main interface class to complete the initialization and logic configuration of the main interface; During the initialization of the main interface, signals and slots are used to connect the main interface actions to the corresponding slot functions. The slot functions call the global cross-process class to trigger the display of the child process interface functions. The main interface is displayed in a non-modal manner by calling the show() method, and the main process's QApplication instance's exec_() method is called to enter the event loop, making the main interface interactive.
[0013] Furthermore, the process of releasing resources and exiting safely includes reclaiming shared memory, closing the database, closing the main process, child processes, and the corresponding main window, and calling the system exit function.
[0014] A second aspect of the present invention provides a Qt-based multi-process management electronic device, including a memory and a processor. The memory includes a Qt-based multi-process management method program, which, when executed by the processor, implements the steps of a Qt-based multi-process management method.
[0015] A third aspect of the present invention provides a computer-readable storage medium including a Qt-based multi-process management method program, wherein when the Qt-based multi-process management method program is executed by a processor, it implements the steps of a Qt-based multi-process management method.
[0016] Compared with the prior art, the beneficial effects of the technical solution of the present invention are: This invention initializes a cross-process communication component at the beginning of the main function and passes in the creation processes of the main process and child process respectively. This allows the main process and child process to run in different independent event loops, thus avoiding the conflicts and UI disorder problems caused by repeated instantiation of QApplication within the same process in existing technologies. By using signals and slots in conjunction with a global cross-process class to implement message passing with the child process in the main process, decoupling and reliable communication between the main process and child process are ensured, improving the smoothness of UI response and reducing the risk of resource contention. Furthermore, this invention enables independent isolation and efficient management of multiple processes and multiple main windows in a cross-platform environment, improving the stability of Qt graphical interface software. Attached Figure Description
[0017] To make the objectives and technical solutions of this invention clearer, the following drawings are provided and described: Figure 1 A flowchart of the method provided in an embodiment of the present invention; Figure 2A screenshot of the main interface of the main process provided in an embodiment of the present invention; Figure 3 A screenshot of the graphical interface of a subprocess provided in an embodiment of the present invention; Figure 4 Screenshots of the main process interface and the chart interface of the child processes provided in this embodiment of the invention. Detailed Implementation
[0018] To better understand the above-mentioned objectives, features, and advantages of the present invention, the present invention will be further described in detail below with reference to the accompanying drawings and specific embodiments. It should be noted that, unless otherwise specified, the embodiments and features described in these embodiments can be combined with each other.
[0019] Many specific details are set forth in the following description in order to provide a full understanding of the invention. However, the invention may also be practiced in other ways different from those described herein, and therefore the scope of protection of the invention is not limited to the specific embodiments disclosed below.
[0020] Example 1: This embodiment addresses the need for visual displacement monitoring (real-time monitoring of two-dimensional displacement through image recognition of targets). The entire project is implemented using Python, with the graphical interface built on the PyQt5 framework, supporting cross-platform operation and visualization research on Windows and Ubuntu platforms. The main interface of the main process is shown below. Figure 2 As shown, the graphical interface of the child process is as follows: Figure 3 As shown, when you click the red text on the main interface, a chart window of the child processes will pop up, as shown below. Figure 4 As shown.
[0021] In the PyQt5 framework, QMainWindow must be created uniquely on the main thread and depends on an instantiated QApplication object. QApplication is the core of a Qt GUI program, responsible for initializing window system integration, managing the event loop (exec_()), and allocating GUI resources such as windows and input methods. Because Qt's GUI modules (QtWidgets) are not thread-safe, the GUI must run on the main thread; QMainWindow, QWidgets, and other controls cannot be created or manipulated directly in a child thread.
[0022] In visual displacement monitoring software, real-time display and management of monitoring results are required. A common approach is to use QDialog pop-ups or QWidgets to draw charts. However, these components run on the main thread, and as the data volume increases, main thread resources are heavily consumed, causing interface lag. Even with sub-threads handling the computation, the single-process limitation cannot prevent main thread blocking, impacting the user experience between chart display and main interface parameter configuration. Furthermore, QDialog pop-ups can only achieve non-modal display via `show()`, making lifecycle management unreliable and prone to issues like unreleased resources or multiple triggers leading to data corruption. Meanwhile, the modal call `exec_()` is insufficient for complex chart management needs.
[0023] Therefore, relying solely on the main thread's QDialog popup is insufficient to implement the status bar, menu bar, and complex interactions required for chart display. After comprehensive consideration, creating a separate QMainWindow for each chart in a multi-process environment becomes a feasible solution to meet the needs of visual displacement monitoring scenarios. To this end, each child process must independently instantiate a QApplication and run its event loop, thus ensuring the independence and stability of the interface interaction. However, Python's multiprocessing mechanism differs between Windows and Linux: Windows uses the spawn method, where newly created child processes re-import and execute the main module, potentially leading to conflicts between multiple QApplications; Linux uses the fork method by default, where child processes inherit the parent process context. Although this has lower resource overhead, it's still necessary to ensure that only one QApplication is created per process; otherwise, the "QApplication already exists" error will still occur.
[0024] It is evident that existing technologies struggle to stably manage multiple QMainWindow processes across multiple platforms, easily leading to dependencies in the initialization order of multiple processes and lacking a unified mechanism for child process communication and lifecycle management.
[0025] This invention provides a Qt-based multi-process management method, such as... Figure 1 The diagram shows a multi-process management method based on Qt. The specific steps are as follows: S1: Initialize the main function and cross-process communication components, and execute the main function.
[0026] More specifically, the main function is initialized only once. Entry protection is set at the beginning of the application's main function, and the initialization logic of the main process is executed only when the program is run as the main process entry point. Example code is shown below: if __name__ == "__main__": app = QApplication(sys.argv) window = ChartWindow() window.show() sys.exit(app.exec_()) Initializing the inter-process communication component involves defining and instantiating a global inter-process class. The instantiated object is then used as a parameter for inter-process communication. This global inter-process class contains mutexes, message queues, and events used for communication across multiple processes. Example code is shown below: from multiprocessing import Lock, Queue, Event S2: Pass the inter-process communication component as a parameter to the child process creation process, create a graph to manage the child process, initialize the child process and execute it, and make the child process enter the waiting state for inter-process communication.
[0027] More specifically, the method for creating a chart management subprocess is through the multiprocessing.Process method.
[0028] The method for initializing and executing the child process involves creating a QApplication instance and using the exec_() method to modally execute the child process's main loop, blocking and waiting for user operation message queues to arrive. This ensures that the child process's main window can execute corresponding menu bar actions and read / write data, facilitating the management of the main window's lifecycle. The child process's main loop includes the following steps: Waiting for main process work instruction messages, such as clicking "View Chart" in the menu bar to display a "pop-up" window; After receiving the work instruction message, create a QtChart chart class that inherits from QMainWindow, instantiate the chart class, and implement the subprocess chart interface functions in the instance, such as initializing the chart interface, periodically reading the visual displacement monitoring results and displaying them on the chart interface in real time, and implementing other functions of the chart interface and pop-up functions. The non-modal display show() method of the chart class and the modal display exec_() method of the child process QApplication are called to block and wait for the user to finish the operation, save the parameters, and close the main window of the chart. After the user closes the main chart window, they wait for the next main process command message, such as waiting for the "View Chart" option in the menu bar to be clicked to display a "pop-up window".
[0029] More specifically, after creating a QApplication instance, a timer (QTimer) is created and started. If the child process does not receive a task from the main process within t milliseconds (in this embodiment, t is 300), the timer triggers and exits the child process's main loop, entering a low-power standby state. It listens for and waits for the main process to send a task instruction to wake up the child process and re-enter the child process's main loop, thus avoiding display disorder of multiple child process main windows. If the child process receives a task from the main process within t milliseconds, such as receiving a "create main window" instruction, the timer is canceled and window creation is executed.
[0030] S3: Pass the inter-process communication component as a parameter into the main process creation process, initialize the main process and execute it, and use signal and slot functions in combination with the global inter-process class to realize communication between the main process and child processes.
[0031] More specifically, initializing and executing the main process includes the following steps: Initialize the main process QApplication instance, QDialog instance, and database and shared memory parameters; Instantiate the main interface class that inherits from QMainWindow to implement the initialization and logic functions of the main interface. Pass the QDialog instance, database and shared memory parameters and global cross-process class as parameters to the main interface class to complete the initialization and logic configuration of the main interface. During the initialization of the main interface, signals and slots are used to connect the main interface actions to the corresponding slot functions. The slot functions call the global cross-process class to trigger the display of child process interface functions (such as "view charts"). The main interface is displayed in a non-modal manner by calling the show() method, and the main process QApplication instance's exec_() is called to enter the event loop, making the main interface interactive (e.g., in the main interface of the software, the main logic of visual displacement monitoring, function parameter configuration and chart display are managed as independent processes).
[0032] S4: If the user closes the main window modal display of the main process, release resources and exit safely.
[0033] More specifically, the process of releasing resources and exiting safely includes reclaiming shared memory, closing the database, closing the main process, child processes, and the corresponding main window, and calling the system exit function.
[0034] This invention breaks through the limitations of PyQt's single-process GUI, and for the first time implements multiple QMainWindow instances running independently in different processes in a Python environment, avoiding resource contention and blocking on the main thread, and significantly improving interface response speed and overall performance.
[0035] Secondly, this invention proposes a mechanism for unified management of child process windows by the main process. Multiple main windows run in independent processes, supporting lifecycle control such as window startup, closing, and restart, ensuring proper resource release and avoiding window state chaos. Simultaneously, modal window management is implemented using `exec_()` in the child processes, solving the problem of uncontrollable lifecycles in traditional QDialog pop-ups and providing a more natural interactive experience.
[0036] Furthermore, this invention innovatively combines inter-process communication mechanisms (such as Queue, Event, etc.) with GUI window management to achieve data synchronization, event response, and status updates between the main window and child windows, thereby improving the overall collaborative capability of the system and supporting complex UI layouts to meet diverse needs such as chart display, status bar, and toolbar.
[0037] Furthermore, this invention addresses the differences between Windows' spawn mode and Linux's fork mode by proposing a process isolation mechanism at the main function entry point: if__name__=="__main__":. This ensures stable operation across all platforms and avoids conflicts between multiple QApplications caused by repeated module execution.
[0038] Finally, this invention adopts a multi-process architecture to enable independent operation, independent development, and independent packaging of window modules. This not only improves the maintainability and scalability of the system, but also allows the creation, communication, and management of multiple main windows to be completed through a single software project, meeting the deployment requirements on Windows and Ubuntu platforms. Each window module can be independently packaged into an executable file, improving source code protection and system security.
[0039] The present invention implements a single-software application that manages multiple main windows in Python code, and runs the main code in the PyCharm environment. The main code is executed via the Python interpreter on both Windows and Ubuntu platforms. Verification shows that running multiple QApplications in a multi-process environment does not result in any conflicts. Subsequently, pyinstaller is used to package the entire project based on the main code, generating the executable program main.exe, which is then run on the Ubuntu platform.
[0040] During operation, the software executes visual displacement monitoring business logic. After monitoring starts, the monitoring data results are displayed approximately every 30 minutes via the "View Charts" function. After 48 hours of continuous operation, the main interface remained smooth and lag-free, and all menu functions functioned correctly. After closing the main interface window, data and parameter saving were completed successfully, and software resources were fully released, verifying the stability and reliability of the technical solution.
[0041] Furthermore, this solution is not only applicable to scenarios involving the management of multiple chart windows, but can also be extended to the following areas shown in Table 1: Table 1
[0042] Example 2: This embodiment provides a Qt-based multi-process management electronic device, including a memory and a processor. The memory includes a Qt-based multi-process management method program. When the Qt-based multi-process management method program is executed by the processor, it implements the steps of a Qt-based multi-process management method as described in Embodiment 1.
[0043] Example 3: This embodiment provides a computer-readable storage medium, which includes a Qt-based multi-process management method program. When the Qt-based multi-process management method program is executed by a processor, it implements the steps of a Qt-based multi-process management method as described in Embodiment 1.
[0044] Obviously, the above embodiments of the present invention are merely examples for clearly illustrating the present invention, and are not intended to limit the implementation of the present invention. Those skilled in the art can make other variations or modifications based on the above description. It is neither necessary nor possible to exhaustively describe all embodiments here. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of the present invention should be included within the scope of protection of the claims of the present invention.
Claims
1. A multi-process management method based on Qt, characterized in that, Includes the following steps: Initialize the main function and inter-process communication components, and then execute the main function. The cross-process communication component is passed as a parameter to the child process creation process, a graph is created to manage the child process, the child process is initialized and executed, and the child process enters a waiting state for cross-process communication. The cross-process communication component is passed as a parameter to the main process creation process, the main process is initialized and executed, and communication between the main process and child processes is achieved by using signal and slot functions in combination with a global cross-process class. If the user closes the modal display of the main process, release resources and exit safely.
2. The Qt-based multi-process management method according to claim 1, characterized in that, The main function is initialized only once. Entry protection is set at the beginning of the application's main function. The initialization logic of the main process is executed only when the program is run as the main process entry point.
3. The Qt-based multi-process management method according to claim 1, characterized in that, The initialization of the inter-process communication component involves defining and instantiating a global inter-process class, and using the instantiated object as a parameter for inter-process communication. The global inter-process class includes a mutex lock, a message queue, and events.
4. The Qt-based multi-process management method according to claim 1, characterized in that, The method to create a chart management subprocess is through the multiprocessing.Process method.
5. A multi-process management method based on Qt according to claim 1, characterized in that, The method for initializing and executing a child process involves creating a QApplication instance of the child process and using the exec_() method to modally execute the child process's main loop. The child process's main loop includes the following steps: Waiting for the main process's work instruction message; Upon receiving a work instruction message, create a QtChart chart class, instantiate the chart class, and implement the child process chart interface functionality within the instance; The non-modal display method show() of the chart class and the modal display method exec_() of the child process QApplication are called, blocking and waiting for the user to finish the operation and close the main chart window; After the user closes the main chart window, they wait for the next main process work instruction message.
6. The Qt-based multi-process management method according to claim 5, characterized in that, After creating a QApplication instance, a timer is created and started. If the child process does not receive a work task from the main process within t milliseconds, the timer triggers and exits the child process's main loop, entering a low-power standby state. It then listens for and waits for the main process to send a work instruction to wake up the child process and re-enter the child process's main loop. If the child process receives a work task from the main process within t milliseconds, the timer is canceled.
7. A multi-process management method based on Qt according to claim 1, characterized in that, Initialize and execute the main process, including the following steps: Initialize the main process QApplication instance, QDialog instance, and database and shared memory parameters; Instantiate the main interface class, and pass the QDialog instance, database and shared memory parameters and global cross-process class as parameters to the main interface class to complete the initialization and logic configuration of the main interface; During the initialization of the main interface, signals and slots are used to connect the main interface actions to the corresponding slot functions. The slot functions call the global cross-process class to trigger the display of the child process interface functions. The main interface is displayed in a non-modal manner by calling the show() method, and the main process's QApplication instance's exec_() method is called to enter the event loop, making the main interface interactive.
8. The Qt-based multi-process management method according to claim 1, characterized in that, The process of releasing resources and exiting safely includes reclaiming shared memory, closing the database, closing the main process, child processes, and the corresponding main window, and calling the system exit function.
9. A Qt-based multi-process management electronic device, characterized in that, The electronic device includes a memory and a processor. The memory includes a Qt-based multi-process management method program. When the Qt-based multi-process management method program is executed by the processor, it implements the steps of a Qt-based multi-process management method as described in any one of claims 1 to 8.
10. A computer-readable storage medium, characterized in that, The computer-readable storage medium includes a Qt-based multi-process management method program, which, when executed by a processor, implements the steps of a Qt-based multi-process management method as described in any one of claims 1 to 8.
Citation Information
Patent Citations
Qt interface integration method and device
CN114356435A