Windows下Python事件循环中启动外部程序的延迟问题排查

Wow, that's a truly tricky issue you've been wrestling with for weeks—GUI apps freezing external tools when a blocking call follows their launch sounds like one of those weird OS-level quirks that makes you pull your hair out. Let's break down what's happening and how to fix it.

Core Behavior Recap #

Your tests clearly highlight the pattern that's key to solving this:

• No GUI + launch tool + sleep: Works immediately (Version 1)
• GUI + launch tool + no sleep: Works immediately (Version 2)
• GUI + launch tool + sleep: Tool freezes until sleep ends or 15-30s pass (Version 3)

This points directly to your GUI's main thread being blocked as the root cause. Here's why that impacts even a separate external process on Windows:

Why This Happens on Windows #

Windows GUI apps depend on a continuous message loop to handle events (drawing windows, processing input, etc.). When you call time.sleep(60) in the main GUI thread, you completely pause this loop.

Even though tool.exe is a separate process, Windows has under-the-hood interactions that can cause it to hang:

1. Parent/child message routing: Some child GUI processes implicitly rely on the parent's message loop for initialization steps, especially if they share desktop or thread context.
2. Unhandled standard streams: If tool.exe tries to read from stdin or write to stdout/stderr and those streams aren't redirected, it may block waiting for the parent process to handle them—something that can't happen while the parent's main thread is asleep.

Actionable Fixes #

Let's go through solutions ordered by how clean and sustainable they are:

1. Move Blocking Work to a Separate Thread (Best Practice)

Never block the GUI main thread—it's a cardinal rule for responsive apps. Use Python's threading module to run your long-running task in the background, leaving the main thread free to handle the message loop.

Adjusted PySide2 Version 3 example:

from PySide2 import QtWidgets
import subprocess
import time
import threading

class Button(QtWidgets.QPushButton):
    def __init__(self):
        super().__init__()
        self.clicked.connect(self.start)

    def start(self):
        # Launch the tool with decoupled streams
        subprocess.Popen('tool.exe', 
                         stdin=subprocess.DEVNULL, 
                         stdout=subprocess.DEVNULL, 
                         stderr=subprocess.DEVNULL)
        # Run blocking task in a background thread
        threading.Thread(target=self.long_running_task, daemon=True).start()

    def long_running_task(self):
        time.sleep(60)

app = QtWidgets.QApplication()
button = Button()
button.show()
app.exec_()

Tkinter equivalent:

import subprocess, tkinter, time, threading

def long_running_task():
    time.sleep(60)

root = tkinter.Tk()
subprocess.Popen('tool.exe', 
                 stdin=subprocess.DEVNULL, 
                 stdout=subprocess.DEVNULL, 
                 stderr=subprocess.DEVNULL)
threading.Thread(target=long_running_task, daemon=True).start()
root.mainloop()

2. Redirect Standard Streams for the External Process

Even without threads, redirecting stdin, stdout, and stderr can prevent tool.exe from blocking waiting for your parent process to handle those streams. Add these arguments to subprocess.Popen:

subprocess.Popen('tool.exe', 
                 stdin=subprocess.DEVNULL, 
                 stdout=subprocess.DEVNULL, 
                 stderr=subprocess.DEVNULL,
                 creationflags=subprocess.DETACHED_PROCESS)

The DETACHED_PROCESS flag fully decouples the child process from the parent, reducing unintended interactions.

3. Manually Pump Events (Quick Hack, Not Ideal)

As you discovered, calling QCoreApplication.processEvents() (or root.update() in Tkinter) during the blocking task keeps the message loop alive. This is a temporary fix though—you'll need to call it repeatedly, and it doesn't address the root issue of blocking the main thread:

def start(self):
    subprocess.Popen('tool.exe')
    # Pump events every 0.1s for 60 seconds
    for _ in range(600):
        time.sleep(0.1)
        QtWidgets.QCoreApplication.processEvents()

Why Your Earlier Fixes Didn't Work #

• os.startfile or batch files: They still launch the process in a context tied to your blocked main thread.
• CREATE_NEW_PROCESS_GROUP: This helps with signal handling but doesn't fix the message loop blocking problem.
• multiprocessing: Overkill, and you'd still hit the same issue if the main thread remains blocked after launching the process.

内容的提问来源于stack exchange，提问作者johnson