Shared subprocess impl

docs/subprocesses.rst

@@ -6,6 +6,11 @@ Using subprocesses
 AnyIO allows you to run arbitrary executables in subprocesses, either as a one-shot call
 or by opening a process handle for you that gives you more control over the subprocess.
 
+On the asyncio backend, subprocess support now also works on Windows when the event loop
+is a ``SelectorEventLoop``. Since that event loop cannot perform pipe I/O for
+subprocesses directly, AnyIO handles the subprocess pipes on a background
+``ProactorEventLoop`` (or winloop) thread instead.
+
 You can either give the command as a string, in which case it is passed to your default
 shell (equivalent to ``shell=True`` in :func:`subprocess.run`), or as a sequence of
 strings (``shell=False``) in which case the executable is the first item in the sequence
@@ -55,6 +60,15 @@ launch one with :func:`~open_process`::
 
 See the API documentation of :class:`~.abc.Process` for more information.
 
+There are a few important process semantics to be aware of:
+
+* :meth:`~.abc.Process.wait` returns as soon as the subprocess exits; it does not wait
+  for ``stdout`` or ``stderr`` to close
+* :attr:`~.abc.Process.returncode` reflects the real exit status once the subprocess has
+  exited, even if :meth:`~.abc.Process.wait` was never called
+* calling :meth:`~.abc.Process.terminate`, :meth:`~.abc.Process.kill` or
+  :meth:`~.abc.Process.send_signal` on an already-exited process is a no-op
+
 .. _RunInProcess:
 
 Running functions in worker processes

docs/versionhistory.rst

@@ -5,6 +5,26 @@ This library adheres to `Semantic Versioning 2.0 <http://semver.org/>`_.
 
 **UNRELEASED**
 
+- Added support for running subprocesses on the asyncio ``SelectorEventLoop`` on Windows,
+  which does not support subprocesses natively; the pipe I/O is handled on a background
+  ``ProactorEventLoop`` (or winloop) thread
+  (`#1235 <https://github.com/agronholm/anyio/pull/1235>`_; PR by @graingert)
+- Changed subprocess handling to use a shared, backend-agnostic implementation built on
+  ``subprocess.Popen()`` plus a small set of backend primitives (asynchronous pipes and
+  child-process reaping). This is used by the asyncio backend on all platforms and by the
+  Trio backend on POSIX (Trio keeps its native implementation on Windows), and removes the
+  reliance on undocumented backend internals
+  (`#783 <https://github.com/agronholm/anyio/issues/783>`_; PR by @graingert)
+- Fixed several inconsistencies between the asyncio and Trio backends when working with
+  subprocesses (`#828 <https://github.com/agronholm/anyio/discussions/828>`_; PR by
+  @graingert):
+
+  * ``Process.wait()`` no longer waits for the standard streams to close, so it returns
+    promptly once the process exits, even when a pipe is inherited by a grandchild process
+  * ``Process.returncode`` now polls the process on both backends, so it no longer returns
+    a stale ``None`` after the process has exited
+  * Signalling an already-exited process via ``terminate()``, ``kill()`` or
+    ``send_signal()`` is now consistently a no-op instead of raising on asyncio
 - Changed the default name for a task spawned with ``TaskGroup.create_task(func())`` to
   match the default task name for the analogous task spawned with
   ``TaskGroup.start_soon(func)`` or ``TaskGroup.start(func)`` in more situations.