I am writing a multithreaded console application in C++11. I would love for it to be OS independent, but I am on a linux machine.
I want to be able to pause threads upon a keypress, but for the program to be allowed to finish and exit without any keypresses as well. Currently my pseudocode for my main thread is the following.
while other threads are executing
sleep for 1 second
if keypress
*do stuff*
end if
end while
So it's something like a busywait. I was wondering if there is a better way to do this.
One way to accomplish it (also in a cross-platform manner) is to use libSDL's, SDL_KeyboardEvent.
Related
Usually when I run a program in terminal I am able to stop it with control C.
When I wrote a program which invoke an operating system command inside a while loop, the rest of the code executes so fast that there is no way to stop the program other than to kill the pid. The way I have been doing is adding a sleep for 1 second but it is not a good practice to fix it.
while(!phrasespotted){
invoke an operating system command to arecord for 5 secs, during which control C can not stop the program
process the audio for phrase spotting
sleep(1); //during this I can stop the program in terminal
}
What do I add to my code so that it can pick up the keyboard interrupt while making the system call, or even register it to stop it immediately after?
Is threading the only option based on catching the signal? https://www.thegeekstuff.com/2012/03/catch-signals-sample-c-code/
I have a call to an external program that opens a "modal" window, since it's in the same thread as the main loop it blocks redrawing of the underlying window.
The program runs as a separate process and I am communicating with the program via pipes.
From what I've read it's bad practice to have an additional main loop, so what is the correct way to avoid this lockup?
The question is how to make a separate thread in my own program to do the communication with that program without blocking the entire main loop.
Use a non blocking API to run the external program, such as GSubprocess https://developer.gnome.org/gio/stable/GSubprocess.html or the lower level spawn API https://developer.gnome.org/glib/stable/glib-Spawning-Processes.html
You could also use a thread but the above APIs are much easier.
You have to somehow return control to the main loop while the subprocess runs, that's the bottom line.
Hi all~ I have a problem boring me so much.
Sometimes when I exit my program, there are some thread still running, in Linux system, it will cause crash after I quit the main loop. Is there any method that can kill all threads when I quit main loop?
It would help a lot if you specified your programming language and threading library of choice.
The usual way to control this type of situation (that is for a parent thread to wait until children complete before terminating) is to call a function supplied by the library, usually named join or wait.
pthread supplies you with pthread_join, for example.
If you're spawning processes via fork, you should use wait or waitpid in the parent to halt until the child completes - try man waitpid or take a look at this.
This way you can inform your children that you are about to exit via the usual means, wait until they wrap up and terminate, then cleanly exit the main loop.
Does this help? This is the least brutal way of synchronizing termination, if you want to actively kill the children threads there are alternatives, of course (like pthread_kill for pthreads, for example).
If you are using java try using the jconsole (Java Monitoring & Management Console) shipped with jdk6u23 in my case. You can get the thread name that is not killed. You can use join for that thread to complete.
But there can be program issue like, in my case i had a timer thread hanging [Timer-0] java.util.Timer to make an a timer.cancel() which closed that timer.
Im making a PyQt4 app which calls Imagemagick and ffmpeg, but it takes too much to complete the tasks and im wondering if there is a way to implement threads to this, the app is going to run in a multicore machine, and some of the methods I have seen are not efficient enough. Thanks in advance
The answer is yes and no - you can use QThread for threading but you'll still be subject to the GIL, so your threads will run in serial.
You could try using multiprocessing to create a worker class in its own process and send work to it (or have it steal work from a queue), however this could introduce its own performance penalties in copying objects and sending objects between processes...
Having re-read your question, it looks like Imagemagick and ffmpeg are external executables, in which case the GIL is released while you wait for the process to execute. Can I ask how you run these though? I tend to find that it is better to create a work queue and an event loop. Each time round the event loop you check whether your running process(es) have finished and then get their output. For this subprocess.Popen is more useful than os.command.
If you use a QTimer you can utilise your QApplication's event loop, which also has the added benefit of allowing your GUI (assuming you have one) to be refreshed between ticks.
Is it possible for a parent process to start and stop a child (forked) process in Unix?
I want to implement a task scheduler (see here) which is able to run multiple processes at the same time which I believe requires either separate processes or threads.
How can I stop the execution of a child process and resume it after a given amount of time?
(If this is only possible with threads, how are threads implemented?)
You could write a simple scheduler imitation using signals.
If you have the permissions, then stop signal (SIGSTOP) stops the execution of a process, and continue signal (SIGCONT) continues it.
With signals you would not have any fine grained control on the "scheduling",
but I guess OS grade scheduler is not the purpose of this execersice any way.
Check kill (2) and signal (7) manual pages.
There are also many guides to using Unix signals in the web.
You can use signals, but in the usual UNIX world it's probably easier to use semaphores. Once you set the semaphore to not let the other process proceed, the scheduler will swap it out in the normal course of things; when you clear the semaphore, it will become ready to run again.
You can do the exact same thing with threads of course; the only dramatic difference is you save a heavyweight context switch.
Just a side note: If you are using signal(), the behavior may be different on different unixes. If you are using Linux, check the "Portability" section of the signal manpage, and the sigaction manpage, which is preferred.