Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Subprocesses and Multiprocessing #308

Open
awvwgk opened this issue Jan 26, 2021 · 3 comments
Open

Subprocesses and Multiprocessing #308

awvwgk opened this issue Jan 26, 2021 · 3 comments
Labels
topic: utilities containers, strings, files, OS/environment integration, unit testing, assertions, logging, ...

Comments

@awvwgk
Copy link
Member

awvwgk commented Jan 26, 2021

Motivation

Spawning or forking synchronous and asynchronous processes in an Fortran application is currently not easily doable in a cross-platform way. This is usually required for job servers which cannot access a functionality from a dynamically loaded library but have to access this functionality by other means, e.g. invoking a program with some input (standard input, files or arguments) and processing its output (standard output or files). Redesigning the functionality to allow dynamically loading symbols is not always possible or desirable.

A current alternative is the execute_command_line which allows to create a new shell or CMD instance, which in turn can invoke commands. Together with OpenMP, MPI or coarrays this can be done even asynchronous but is tedious and somewhat errorprone. Using a shell or CMD instance has some security and speed implications as well.

Possible API

  • procedural API similar to POSIX API (basically thin iso_c_binding wrapper)
  • object oriented API similar to Python's subprocess module

Available Implementations

Feel free to add entries to this list.

For POSIX API:

For Windows API?

@ivan-pi
Copy link
Member

ivan-pi commented Jan 26, 2021

I few months ago I was trying to replicate the process API from Rust. Ultimately, I got stuck exactly on this issue and tried to solicit some help/ideas at Fortran Discourse: https://fortran-lang.discourse.group/t/ideas-for-command-module/439/4

A number of Fortran Posix API's are linked here: #22 (comment) It's a shame the Fortran community didn't unite earlier, and instead allowed compiler vendors to role out several incompatible Posix interfaces.

Edit: the C runtime library for Microsoft Windows has the _spawn, _wspawn Functions which seem to fit the purpose.

@awvwgk awvwgk added the topic: utilities containers, strings, files, OS/environment integration, unit testing, assertions, logging, ... label Feb 3, 2021
@ivan-pi
Copy link
Member

ivan-pi commented Feb 10, 2021

I found a document which describes signal handling in Fortran: https://www.sharcnet.ca/help/images/4/42/Fortran_Signal_Handling.pdf

Some compilers already provide extensions, in gfortran the subroutine signal is available.

@awvwgk
Copy link
Member Author

awvwgk commented Feb 10, 2021

Signal handling might deserve an issue on its own, what do you think?

From my experience the signal extension in gfortran and ifort is not really satisfactory, therefore I usually resort to install signal handlers via C. I use it to gracefully catch SIGINT and SIGTERM and shut down the program, depending on your compiler those are most likely completely ignored by default which makes it a pain to kill a Fortran program.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
topic: utilities containers, strings, files, OS/environment integration, unit testing, assertions, logging, ...
Projects
None yet
Development

No branches or pull requests

2 participants