Current API Proposal
I have built the subroutine around the type(process_type) already part of the module
! signal: integer (signal number)
! success: logical (true if the operation was succesfull, false otherwise)
call send_signal(process, signal, success)
Comments
The actual functionality is implemented in C using kill
After sending the signal it updates the state of the process once without blocking
As different processes react differently to different signals, the handling of the process after sending a signal is left to the user (like checking if the process has exited after some cleanup, after some time etc)
It does nothing on the Windows operating system (as there is no concept of signals there)
I would like to know if the community is interested in such functionality as part of stdlib, this question I feel is a part of a bigger question if stdlib should include important OS-specific functionality, not all of them of course, but the ones we find ourselves repeatedly implementing.
Looking forward to hearing all of your thoughts on either the technical aspects of the implementation and/or the inclusion of OS-specific important routines (feel free to suggest the exact procedures you would like too!)
I’m not sure… It can make sense when the functionality is present on most of the OS’s, but just implemented differently: having an OS-independent wrapper can then be nice. If the functionality is completely absent from a major OS it’s a different story.
Actually, the Fortran standard itself allows for such features. For instance the system_clock routine and the KIND mechanism in general. So I do not see any reason not to permit something similar in Stdlib, as long as it is clearly documented.
One can argue that a clock is actually “present on most of the OS’s”.
Regarding the available KINDs, it is processor-dependent, rather than OS dependent. And the standard states some constraints (there must be a real kind with at least 10 digits precision, and an integer kind with at least 18 digits range)
Apart from this, I found a simple C program that illustrates the use of signals (in the pedestrian and discouraged way) that actually runs fine on Windows, using gcc:
xample usage
#include <signal.h>
#include <stdio.h>
#include <stdlib.h>
volatile sig_atomic_t status = 0;
static void catch_function(int signo) {
status = signo;
}
int main(void) {
// Set above function as signal handler for the SIGINT signal:
if (signal(SIGINT, catch_function) == SIG_ERR) {
fputs("An error occurred while setting a signal handler.\n", stderr);
return EXIT_FAILURE;
}
puts("Raising the interactive attention signal.");
if (raise(SIGINT)) {
fputs("Error raising the signal.\n", stderr);
return EXIT_FAILURE;
}
if (status == SIGINT) puts("Interactive attention signal caught.");
puts("Exiting.");
return EXIT_SUCCESS;
// exiting after raising signal
}
So, it may not be all this OS specific. At least not when you approach in this naïve way.
As @FedericoPerini asked in the PR, which functionality beyond killing a process would be possible through this extended API? I wonder, would TCP/IP be a possibility? To which extent? What about interaction with GUIs?
Would something similar to what @Arjen showed work with intel? If a solution can be found to work with gnu and intel compilers AND on windows and linux, the discussion about its implementation in stdlib would be easier.
Actually, the example I posted can be readily built on Windows with MicroSoft’s cl and Intel oneAPI’s icx compilers. The resulting programs show the exact same output as the program I built with gcc.
which functionality beyond killing a process would be possible through this extended API? I wonder, would TCP/IP be a possibility? To which extent? What about interaction with GUIs?
The functionality this can achieve purely depends on the process receiving the signal (except SIGKILL) , Sure there are some widely agreed conventions like receival of SIGTERM should make the process prepare for exit by performing necessary cleanups to properly exit without any side effects, but it is not necessary that all processes conform to this convention. The signals are similar to messages so there is no additional payload that can be sent with them, so no possibility of TCP/IP. The same is true for interaction with GUI’s, it depends on the particular process.
If a solution can be found to work with gnu and intel compilers AND on windows and linux, the discussion about its implementation in stdlib would be easier.
Although the example @Arjen showed works, it is better to not use <signal.h> on Windows due to a wide range of differences with the Unix version, some of which are documented here
The more I research on this topic the more I found out that this cannot really be made cross-platform (feel free to correct me if anyone thinks I am wrong abut this), But I would not say this is too niche as it works on Unix based systems (MacOS, Linux, BSD Variants)