Unify process termination on POSIX & Windows (+ tests)

[felixweinberger]

Motivation and Context

#555, #559 address important but different ways MCP servers can hang or fail to successfully terminate on Windows & POSIX systems.

This PR re-implements #555 by aligning process termination between Windows and Unix to make sure SIGTERM-ignoring processes don't inadvertently cause hangs.

How Has This Been Tested?

New regression tests added for #555 and #559. These were developed and tested on both POSIX and Windows systems.

• Original authors: @cristipufu, @LionNatsu

Breaking Changes

None.

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Documentation update

Checklist

• I have read the MCP Documentation
• My code follows the repository's style guidelines
• New and existing tests pass locally
• I have added appropriate error handling
• I have added or updated documentation as needed

Additional context

[jingx8885]

Verification of Windows Process Tree Termination Fix
(Originally encountered in #729 context)

Scenario:
In a Python MCP server (uv-pyproject structure) using stdio mode launched via:
uv run --env-file=xxx mcp_server.py

We observed the following process hierarchy:

Python parent process  
  → Python subprocess (middle layer)  
    → uv.exe  
      → MCP stdio service  

Failure:
Terminating the middle Python subprocess failed to terminate its descendants, leaving:

1. uv.exe process
2. MCP stdio service process

...as orphaned/zombie processes on Windows.

Validation:
➡️ This specific failure mode was resolved by the process termination logic **originally implemented in #729 **.
➡️ The equivalent solution now exists in #1044's unified approach.
➡️ This logic has been production-validated on Windows 11 across:

• Live production systems
• Daily development/testing cycles
• High-frequency restart scenarios

Conclusion:
#1044 successfully addresses this Windows-specific process tree termination flaw. The child process cleanup behavior required for this scenario is correctly implemented.

[felixweinberger]

After receiving offline feedback from @dsp-ant I'm splitting this PR into 2:

• This PR will keep the changes from Fix stdio_client kill process after timeout #555 Fix hanging on streams when stdio_client exiting #559 Align stdio shutdown sequence with spec #765
• Improve child process termination on POSIX & Windows #1078 will house the changes Subprocess kill win32 #729 Fix child process kill error with npx based servers #850 - there's some rework needed to avoid race conditions

FYI for @jingx8885 @surya-prakash-susarla, it's currently in draft and still needs work, I'll tag you once its ready

[Kludex]

@agronholm Should we have to create OSS specific logic for termination when using anyio.open_process?

[agronholm]

@agronholm Should we have to create OSS specific logic for termination when using anyio.open_process?

I'm not sure I follow. Can you give me more context? I'm very new to this project.

[felixweinberger]

Hi @Kludex, @agronholm thanks for taking a look!

For context, we actually don't spawn windows processes with anyio.open_process on Windows anymore since #596. We now use subprocess.Popen - the reason was that trying to spawn processes with anyio way was causing NotImplementedError on Windows when using the SelectorEventLoop (apparently the default for Python 3.13+ and e.g. in Streamlit, Google AgentKit google/adk-python#1321), which was blocking Windows development of MCP servers in those environments.

However, your comment made me realize that we should probably explicitly guard for that case and still use anyio by default if possible as a first try, so I added a commit on top of this PR to attempt with anyio first and only in the NotImplementedError case use the FallbackProcess wrapper.

If this could somehow be fixed upstream in anyio that would of course be fantastic - though we did get feedback from Microsoft that Python's asyncio is relatively underdeveloped on Windows, which might be a root cause why we ran into this issue in the first place and might make it difficult to address there?

[agronholm]

Any idea why SelectorEventLoop would be the default there? It stopped being the Python default on Windows on Python 3.8.

[felixweinberger]

Any idea why SelectorEventLoop would be the default there? It stopped being the Python default on Windows on Python 3.8.

@agronholm Doing some research based on what @theailanguage raised in #596:

1. Streamlit:

• Discussion in Fix Windows subprocess NotImplementedError (STDIO clients) #596 concerns Streamlit on Windows (cc @theailanguage)

2. MCP Adapters:

• NotImplementedError with MultiServerMCPClient on Windows due to SelectorEventLoop langchain-ai/langchain-mcp-adapters#25 open, showing the same NotImplementedError with SelectorEventLoop on Windows

3. Jupyter Notebooks (outdated, but as examples):

• Default event loop in Notebook 6.1.6 on Windows is not ProactorEventLoop jupyter/notebook#5916 opened January 2021 for Jupyter Notebook 6.1.6
• Not using Proactor event loop by default on Windows with Python 3.10 jupyterlab/jupyterlab#12545 opened May 2022 for JupyterLab with Python 3.10
• Both resolved now but show that subprocesses (in this case ipykernel?) were using unexpected event loops on windows.

It seems that while the ProactorEventLoop is the default on Python 3.8+ on Windows, that doesn't necessarily carry over to all applications that might set the event loop internally to SelectorEventLoop for some reason? In such cases this leads to a NotImplementedError