When one is interactively using cmd.exe to run all sort of windows CLI application, one can easily stop them by pressing CTRL+C or CTRL+BREAK . this is implemented by signaling the process as can be read here. As for cmd.exe itself, it does not terminate in these conditions as can be explained in a comment of this question.
Now, consider the following scenario. My application open a cmd.exe using CreateProcess(), and the user has started another application b.exe through it. Say that my application want to fold before b.exe has ended , and it doesn't really care about the graceful termination of it. optimally, I'd like to mimic the user pressing CTRL+C and then send exit to the cmd.exe (let's say I can do it IO-wise). the windows api offers GenerateConsoleCtrlEvent() for that (almost) exact purpose, but it can be ignored by the process (cmd.exe in that case) and in particular , it won't forward the signal to b.exe.
Related
I have a python script who sends a SIGHUP signal to another process, unrelated with my script (not a child, not alterable). When the process receives the SIGHUP, it starts a "light restart", reloading configuration file and updating information.
The "restart" doesn't stop the process, so I can't wait for an exit code. I know I can look at the process log file to know if the signal is handled, but that's too heavy and too slow for the script flow.
I would like to know if I can use another method to be warned that the SIGHUP have been received by my process?
The inotify-tools C library may solve your problem. Its installation gives you access to new commands: inotifywait and inotifywatch.
Let's say you have this /tmp/foo.bar file. You can start watching for any read access on this file with the following command:
inotifywait --event access /tmp/foo.bar
Then, do a cat /tmp/foo.bar and the program will return.
As I said, it's a C library and I guess there are other language implementations of it. So feel free to not use this Bash example and write you own program using this library.
I have written a C++ program and I am executing in the gnome terminal (I am on Ubuntu). I press Ctrl + Z, which suspends the process. Later on, I execute % on the same terminal, which resumes execution.
From what I've read, Ctrl+Z sends a TSTP signals to the process, which tells it to stop execution. But TSTP is polite, in the sense that the process is allowed to continue until it decides it can stop. In my C++ program code, I didn't do anything to explicitly deal with TSTP signals. So, my question is, what things inside my C++ code will continue running in spite of the TSTP signal? For example, if I have a file stream open, will it wait until it is closed? I expect an overall answer, not too deep or covering all the details. I just want an idea of how this happens.
Your program continues running while the SIGTSTP handler executes. Since you haven't set one up, you get the default signal handling behavior, which is for the process to be stopped.
While your process is stopped, it simply isn't scheduled for execution. Files don't get closed, nor is stopping delayed until files get closed (unless done in the signal handler).
This website looks like it has a helpful explanation of how a handler can be installed to perform some tasks and then have the default stopping behavior:
http://man7.org/tlpi/code/online/dist/pgsjc/handling_SIGTSTP.c.html
I am writing a program which is used to launch different command line applications. The problem is when I run 1 application, command prompt takes control of the program and will not allow me to access my GUI to launch another. I believe this is because System() creates a new process, Then once the command prompt is exited, control is given back to the GUI.
Is there any alternatives that will allow me to Launch several command line programs at once ? like in a thread for example.
Any help on this would be greatly appreciated.
::Dan
Use the CreateProcess function; this create a new process but doesn't wait for it to finish. Instead, you can wait for it yourself using the WaitForSingleObject function.
If you are starting multiple processes you may want to consider using WaitForMultipleObjects which lets you wait for a whole list of processes (and other objects) at once.
See the list of wait functions at the MSDN for more alternatives on how to wait for a process to finish.
In my c++ program, I try to run programs in the background by simply not waiting for them.
However in Linux, if I start vi in the background like this: vi &, then vi doesn't show up. In my program, vi will still pop up even if I don't wait for it to terminate.
So does that mean that I'm not really running it in the background? How can this be fixed?
Also, I noticed that in Linux if I type fg to bring vi into the foreground, then vi will appear. How can I do this in c++?
What's going on here is rather complicated (for more information than you probably require, see glibc's manual section on job control) but the short version is: Only the foreground process group can access the terminal. Any other process gets automatically ^Zed by the kernel if it tries to access the terminal.
When you fork a process from C, if the parent is in the foreground process group, the child is also considered to be in the foreground process group unless either the parent or the child changes that. When you do vi &, the shell (which is just another C program, remember) takes vi out of the foreground process group. But you're not doing that, so vi runs immediately.
Now, you want to fork a process from your C program and have it be treated the same as if it had been run with & from the shell. You can only do part of that. You can put it into a non-foreground process group -- see the glibc manual for instructions; as I said, it's complicated -- but you can't add it to the list of process groups that the shell's job control commands know about. That list is state internal to the shell, there's no way to get at it from another process.
I am creating an application in C++ gtk and if I press a button a threading process will start and I need to run the application if the window is closed also is it possible?
Under a Unix system (and since Windows 10), you create another process using the fork() function. To run a program you then use the execve() or similar.
However, that means you need to communicate with that other process using a pipe (see pipe() or pipe2()) or via the network.
Using a thread instead of a process allows you to run in the same memory & process and you can very easily shared everything between multiple threads.
As far as I know, the gtk loop just returns once the user selects the "Close Window" or similar exit function. It would be up for your main() function to make sure that it waits for all the threads to be done before exiting. For threads, this is usually done with a "join()". It will depend on the library you use to run your background process.
Note that in most cases people expect processes to exit whenever they ask the process to exit. Showing a window saying that your process is still running in the background (is busy) is a good idea for a process which runs a GUI. Especially, if you run your process from the console, it would not exit immediately after you closed the window, so letting the user know what's happening is important otherwise they are likely to hit Ctrl-C and kill the whole thing.
If you'd like the main to return but be able to keep the background threads running, it's a tad bit more complicated, but it uses both of the solutions I just mentioned:
create a pipe()
fork() (but no execve())
from within the forked app. (child) open Gtk window, background thread, etc.
when last Gtk window is closed, send message over pipe
parent process receives message and quits immediately
child process still attempts a "join()" to wait for the background thread
This way, the background process with threads created in (3) can continue to run (your function still needs to wait for all the threads to end with the "join()" call), however, the use has a sense of "the app. is done" since it returns to the next line on the prompt in your console even though a background process is still running.
The pipe() and wait on a message on the pipe() is not required if you don't mind having your application always running in the background.
Note: that usage of fork() is most often seen when creating processes that want to run in the background (i.e. services, often called servers under Unix). That's how they get their PPID set to 1.
On Windows, you need to create a Windows/Linux/Mac Service or run the process in background. On Linux you need to create a daemon service or run the process in the background. Services allow to automatically start the process on boot.