Processes can be communicated with using standard GIO-style APIs (ie:
gio.input_stream.InputStream, gio.output_stream.OutputStream). There are GIO-style APIs
to wait for process termination (ie: cancellable and with an asynchronous
variant).
There is an API to force a process to terminate, as well as a
race-free API for sending UNIX signals to a subprocess.
One major advantage that GIO brings over the core GLib library is
comprehensive API for asynchronous I/O, such
gio.output_stream.OutputStream.spliceAsync. This makes gio.subprocess.Subprocess
significantly more powerful and flexible than equivalent APIs in
some other languages such as the subprocess.py
included with Python. For example, using gio.subprocess.Subprocess one could
create two child processes, reading standard output from the first,
processing it, and writing to the input stream of the second, all
without blocking the main loop.
A powerful gio.subprocess.Subprocess.communicate API is provided similar to the
communicate() method of subprocess.py. This enables very easy
interaction with a subprocess that has been opened with pipes.
gio.subprocess.Subprocess defaults to tight control over the file descriptors open
in the child process, avoiding dangling-FD issues that are caused by
a simple fork()/exec(). The only open file descriptors in the
spawned process are ones that were explicitly specified by the
gio.subprocess.Subprocess API (unless gio.types.SubprocessFlags.InheritFds was
specified).
gio.subprocess.Subprocess will quickly reap all child processes as they exit,
avoiding ‘zombie processes’ remaining around for long periods of
time. gio.subprocess.Subprocess.wait can be used to wait for this to happen,
but it will happen even without the call being explicitly made.
As a matter of principle, gio.subprocess.Subprocess has no API that accepts
shell-style space-separated strings. It will, however, match the
typical shell behaviour of searching the PATH for executables that do
not contain a directory separator in their name. By default, the PATH
of the current process is used. You can specify
gio.types.SubprocessFlags.SearchPathFromEnvp to use the PATH of the
launcher environment instead.
gio.subprocess.Subprocess attempts to have a very simple API for most uses (ie:
spawning a subprocess with arguments and support for most typical
kinds of input and output redirection). See gio.subprocess.Subprocess.new_. The
gio.subprocess_launcher.SubprocessLauncher API is provided for more complicated cases
(advanced types of redirection, environment variable manipulation,
change of working directory, child setup functions, etc).
gio.subprocess.Subprocess allows the creation of and interaction with child processes.
Processes can be communicated with using standard GIO-style APIs (ie: gio.input_stream.InputStream, gio.output_stream.OutputStream). There are GIO-style APIs to wait for process termination (ie: cancellable and with an asynchronous variant).
There is an API to force a process to terminate, as well as a race-free API for sending UNIX signals to a subprocess.
One major advantage that GIO brings over the core GLib library is comprehensive API for asynchronous I/O, such gio.output_stream.OutputStream.spliceAsync. This makes gio.subprocess.Subprocess significantly more powerful and flexible than equivalent APIs in some other languages such as the subprocess.py included with Python. For example, using gio.subprocess.Subprocess one could create two child processes, reading standard output from the first, processing it, and writing to the input stream of the second, all without blocking the main loop.
A powerful gio.subprocess.Subprocess.communicate API is provided similar to the communicate() method of subprocess.py. This enables very easy interaction with a subprocess that has been opened with pipes.
gio.subprocess.Subprocess defaults to tight control over the file descriptors open in the child process, avoiding dangling-FD issues that are caused by a simple fork()/exec(). The only open file descriptors in the spawned process are ones that were explicitly specified by the gio.subprocess.Subprocess API (unless gio.types.SubprocessFlags.InheritFds was specified).
gio.subprocess.Subprocess will quickly reap all child processes as they exit, avoiding ‘zombie processes’ remaining around for long periods of time. gio.subprocess.Subprocess.wait can be used to wait for this to happen, but it will happen even without the call being explicitly made.
As a matter of principle, gio.subprocess.Subprocess has no API that accepts shell-style space-separated strings. It will, however, match the typical shell behaviour of searching the PATH for executables that do not contain a directory separator in their name. By default, the PATH of the current process is used. You can specify gio.types.SubprocessFlags.SearchPathFromEnvp to use the PATH of the launcher environment instead.
gio.subprocess.Subprocess attempts to have a very simple API for most uses (ie: spawning a subprocess with arguments and support for most typical kinds of input and output redirection). See gio.subprocess.Subprocess.new_. The gio.subprocess_launcher.SubprocessLauncher API is provided for more complicated cases (advanced types of redirection, environment variable manipulation, change of working directory, child setup functions, etc).
A typical use of gio.subprocess.Subprocess will involve calling gio.subprocess.Subprocess.new_, followed by gio.subprocess.Subprocess.waitAsync or gio.subprocess.Subprocess.wait. After the process exits, the status can be checked using functions such as gio.subprocess.Subprocess.getIfExited (which are similar to the familiar WIFEXITED-style POSIX macros).