system: subprocessing interface

[perazz]

With this PR I want to introduce for discussion a comprehensive API for managing external processes in Fortran.
This is a fully cross-platform implementation for synchronous (similar to execute_command_line) or asynchronous (fully detached process) processes, and mimics functionality from the Python subprocess module.

Previous discussion

• Interface to POSIX I/O API #22
• 'Sleep' not working when compiled in Win32 (x86) #738
• Implement sleep #266

Proposed API

Here’s the simplified list of interfaces with their types and example usage:

• type(process_type): A derived type representing the external process state containing the state handler as well as stdin, stdout, stderr as strings.
• run a synchronous (blocking) process:
  process = run(cmd [, stdin=string] [, want_stdout=.false.] [, want_stderr=.false.])
• runasync an asynchronous (non-blocking) process:
  process = runasync(cmd [, stdin=string] [, want_stdout=.false.] [, want_stderr=.false.])
• update query process state and update the state variable:
  call update(process)
• is_running check if a process is still running and update the handler:
  status = is_running(process)
• is_completed check if a process has finished and update the handler:
  status = is_completed(process)
• wait for completion (option for max waiting time in seconds):
  call wait(process [, max_wait_time=10.0])
• elapsed time since process start, or total process lifetime:
  duration = elapsed(process)
• kill a running external process:
  call kill(process, success)
• sleep implementation is moved to C so that a slightly better wrapper based on nanosecond can be used

This provides a concise overview of the interfaces for quick reference.

Key facts

• Traditional Fortran interfaces are used rather than type-bound procedures because that seems more similar to the other stdlib interfaces, but I'm happy to introduce them as well and further discuss the API.
• stderr, stdout, stdin are stored via temporary files, but that is completely internal to the implementation. So, we can later implement faster memory-only communication via pipes without changing the API.
• A cross-platform C interface routine was necessary. Because C macros are more informative, all platform-dependent operation is kept on the C side only.
• Error handling is currently made via integer exit codes. If/when the type(state_type) general error handler is approved, we can improve this and use it throughout the subprocessing API too.

Prior art

• Python subprocess module

[ivan-pi]

Cool addition! I always wanted to have something like this in the past. I wrote my own little experiment once. I started reviewing the Python subprocess module, but got discouraged by the messy implementation details.

[perazz]

Summary of community feedback:

• Have an object-oriented interface in process_type
• Synchronous/Asynchronous run should be accomplished with different function names rather than the optional wait=.true. input variable
• Synchronous/Asynchronous interface: proposed names are either run vs. runasync or run vs start
• Provide an optional callback function interface to be called on project completion
• have a process ID getter interface
• document the additional functionality

[perazz]

I believe all community-requested features have been introduced.

[jvdp1]

Nice PR @perazz . Very valuable additions.
It could be helpful if the changes in stdlib_strings would have its own PR. It would be easier to review, and I believe it could be merged sooner. But it is also ok like this for me.

[jvdp1]

This could have its own PR, as it is not directly associated with this PR (but needed for this PR).

[jvdp1]

Suggested change

	inserting a separator between each string (default: space). A user-defined separator may be provided, The resulting string is returned.
	inserting a separator between each string (default: space). A user-defined separator may be provided. The resulting string is returned.

[jvdp1]

It should be in a separate file.

[jvdp1]

Suggested change

	`want_stderr` (optional): Shall be a logical flag. If `.true.`, the standard error output of the process will be captured. Default: `.false.`. This is an `intent(in)` argument.
	`want_stderr` (optional): Shall be a `logical` flag. If `.true.`, the standard error output of the process will be captured. If `.false.` (default), it will be lost. This is an `intent(in)` argument.

[jvdp1]

I guess this could be easily converted to a full program

[jvdp1]

Suggested change

	`want_stderr` (optional): Shall be a logical flag. If `.true.`, the standard error output of the process will be captured. Default: `.false.`. This is an `intent(in)` argument.
	`want_stderr` (optional): Shall be a `logical` flag. If `.true.`, the standard error output of the process will be captured. Default: `.false.`. This is an `intent(in)` argument.

[jvdp1]

What is the addition of is_completed in comparison to is_running? It seems like the result will always be is_completed(process) == .not.is_running(process)?