I was looking for a way to stop a thread that perform a task every 2 seconds. I decided to try to use a std::promise/future so that the thread can exit immediately when the promise is set.
#include <future>
#include <iostream>
#include <chrono>
#include <csignal>
std::promise<void> stop;
int main() {
std::signal(SIGINT, [] (int) { stop.set_value(); } );
auto future = stop.get_future();
while (future.wait_for(std::chrono::seconds(1)) != std::future_status::ready) {
std::cout << "I'm still there" << std::endl;
}
}
Actually this does not work and crashes that way:
$ ./a.out I'm still there
^Cterminate called after throwing an instance of 'std::system_error'
what(): Unknown error -1 Abandon
(core dumped)
Ok, One should take care of what he does in handler context, but I must say I was not expecting this crash; and I don't really understand it...
Do you have any idea?
I believe what you have here is undefined behaviour as a result of calling a standard library function (not in list of signal safe functions) in the signal handler.
The limitations on the signal handler function (that is user-defined) are extensive and are documented here.
Another thing to watch out for is if the signal handler refers to any object with static or thread-local(since C++11) storage duration that is not std::atomic(since C++11) or volatile std::sig_atomic_t.
And as #BasileStarynkevitch pointed out, if you are on Linux, ensure that only async-signal-safe functions are called from the signal handler.
Related
I was expecting that the status of sub-thread, whether they succeed or not, should not crash main thread.
So I had a quick test:
#include <thread>
#include <iostream>
#include <exception>
using namespace std;
using namespace std::chrono;
void th_function() {
this_thread::sleep_for(chrono::seconds(2));
throw 1; // the criminal here!
}
int main() {
auto th = thread{ th_function };
this_thread::sleep_for(chrono::seconds(1));
cout << "1" << endl;
th.join();
cout << "2" << endl;
return 0;
}
The running result is:
1
Program stderr
terminate called after throwing an instance of 'int'
Well, seems the throw 1 call leads to main thread crash. I think for c++, each thread has its own runtime stack and exception-process chain.
Then why in my case, sub-thread exception will terminate main thread?
Thanks.
It is true that exceptions handling is localized to a single thread, but as always, not catching an exception at all causes a call to std::terminate, which in turn terminates the whole program. The same applies to other conditions resulting in a call to std::terminate, e.g. throwing from a destructor during stack unwinding or letting an exception escape a noexcept function. These are all considered unrecoverable errors.
You can use e.g. std::async if you need to continue execution after an unhandled exception in the thread. std::async includes functionality to catch otherwise uncaught exceptions and stores/forwards them in a std::future, so that the main thread can receive them.
I have simplified my example for an easier explanation. I am writing an application that counts to 100 but at any given time I allow the user to cancel the program by entering ctrl+c through the keyboard.
What seemingly started as a simple program quickly became complicated based on my lack of knowledge on function pointers. This is what I'm attempting to do:
Capture the SIGINT signal when ctrl+c is pressed.
Once captured, call a member function that shuts down a third-party resource.
The catch is that unlike the two examples that Michael Haidl and Grijesh Chauhan give on capturing SIGINT, I am not permitted to store any global variables. The ideal scenario is one in which all variables and function calls related to signal() are encapsulated within a class of mine.
Here's my modified attempt based on Haidl and Grijesh's code:
#include <thread>
#include <chrono>
#include <functional>
#include <iostream>
#include <signal.h>
class MyClass {
public:
volatile sig_atomic_t cancel = 0;
void sig_handler(int signal) {
cancel = true;
this->libCancel();
}
void libCancel() { std::cout << "Cancel and cleanup" << std::endl; }
};
int main(int argc, char *argv[]) {
MyClass mc;
//using std::placeholders::_1;
//std::function<void(int)> handler = std::bind(&MyClass::sig_handler, mc, _1);
//signal(SIGINT, handler);
signal(SIGINT, &mc.sig_handler); // **compiler error**
for (int i = 0; !mc.cancel && i < 100; ++i)
{
std::cout << i << std::endl;
std::this_thread::sleep_for(std::chrono::seconds(1));
}
return 0;
}
As you can see, I'd like the code to simply count to 100 and exit if all goes well. But if the user calls ctrl+c then the class should handle SIGINT, call the external library for cleanup, and the for loop will exit.
The main problem is that I can't seem to setup the signal() declaration to bind to my instance of MyClass::sig_handler. I even tried casting my member function to std::function to be used by signal(), commented out, but the compiler isn't happy about the fact that C++ function<void(int)> isn't equivalent to the C lang void (*)(int).
Any and all criticism is welcome. I'm not at all tied to what I've written and I clearly don't have a great fundamental understanding of how to use function pointers with member functions.
It is not possible to communicate between the signal handler and the rest of the program using local variables. No parameters are passed into the handler other than the raised signal and the handler returns no value.
The words "global variables" are somewhat ambiguous. People sometimes mean different things depending on context. If your restriction applies only to the global scope, then simply use a volatile sig_atomic_t within some namespace. Or use static member variable, if you so prefer.
If your restriction applies to static storage duration, then you can use a thread local variable instead.
If your restriction applies to all global memory, then your problem is unsolvable using a signal handler. You simply need a global variable of some sort.
If you can rely on POSIX rather than C++ standard, A way to handle SIGINT without globals is to make sure that it is not handled, and block the thread with sigwait. If the call returns SIGINT, then stop the program, otherwise do what you want to do with the signal that was caught.
Of course, this means that the blocking thread doesn't do anything other than wait for signals. You'll need to do the actual work in other thread(s).
Technically though, global memory is probably still used. The use is simply hidden inside system library.
Furthermore, it is not safe to use std::cout within a signal handler. I know that is only an example, but "call the external library for cleanup" is very likely also async signal unsafe.
This can be fixed simply by calling the cleanup outside the for loop rather than inside the handler.
The main problem is that I can't seem to setup the signal() declaration to bind to my instance of MyClass::sig_handler.
That's because signal requires a function pointer (of type void(int)). Non-static member functions cannot be pointed by function pointers. They can only be pointed by member function pointers, which signal doesn't accept.
I have a program that uses a timer to set some double buffer in a GUI application. Under some rare circumstances, e.g., while the program is shutting down, I get an error that the promise that sets this buffer is already set. Is there a way to catch that error and deal with it?
Here's a minimal example:
#include <iostream>
#include <boost/thread/future.hpp>
int main()
{
boost::promise<int> promise;
try {
promise.set_value(0);
promise.set_value(0);
} catch (...) {
promise.set_exception(boost::current_exception());
}
return 0;
}
No matter how I try to catch it, it terminates my program with error:
terminate called after throwing an instance of 'boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<boost::promise_already_satisfied> >'
And here you can see it in action.
After set_value another set_value fails and I bet the set_exception in your catch block fails with the same reason: the result (either value or exception) is already set, the promise is already satisfied. At least that is how std::promise works and I would not be surprised if boost::promise works the same.
I'm learning about mutexes in C++ and have a problem with the following code (taken from N. Josuttis' "The C++ Standard Library").
I don't understand why it blocks / throws unless I add this_thread::sleep_for in the main thread (then it doesn't block and all three calls are carried out).
The compiler is cl.exe used from the command line.
#include <future>
#include <mutex>
#include <iostream>
#include <string>
#include <thread>
#include <chrono>
std::mutex printMutex;
void print(const std::string& s)
{
std::lock_guard<std::mutex> lg(printMutex);
for (char c : s)
{
std::cout.put(c);
}
std::cout << std::endl;
}
int main()
{
auto f1 = std::async(std::launch::async, print, "Hello from thread 1");
auto f2 = std::async(std::launch::async, print, "Hello from thread 2");
// std::this_thread::sleep_for(std::chrono::seconds(1));
print(std::string("Hello from main"));
}
I think what you are seeing is an issue with the conformance of the MSVC implementation of async (in combination with future). I believe it is not conformant. I am able to reproduce it with VS2013, but unable to reproduce the issue with gcc.
The crash is because the main thread exits (and starts to clean up) before the other two threads complete.
Hence a simple delay (the sleep_for) or .get() or .wait() on the two futures should fix it for you. So the modified main could look like;
int main()
{
auto f1 = std::async(std::launch::async, print, "Hello from thread 1");
auto f2 = std::async(std::launch::async, print, "Hello from thread 2");
print(std::string("Hello from main"));
f1.get();
f2.get();
}
Favour the explicit wait or get over the timed "sleep".
Notes on the conformance
There was a proposal from Herb Sutter to change the wait or block on the shared state of the future returned from async. This may be the reason for the behaviour in MSVC, it could be seen as having implemented the proposal. I'm not sure what the final result was of the proposal was or its integration (or part thereof) into C++14. At least w.r.t. the blocking of the future returned from async it looks like the MSVC behaviour did not make it into the specification.
It is interesting to note that the wording in ยง30.6.8/5 changed;
From C++11
a call to a waiting function on an asynchronous return object that shares the shared state created
by this async call shall block until the associated thread has completed, as if joined
To C++14
a call to a waiting function on an asynchronous return object that shares the shared state created
by this async call shall block until the associated thread has completed, as if joined, or else time
out
I'm not sure how the "time out" would be specified, I would imagine it is implementation defined.
std::async returns a future. Its destructor blocks if get or wait has not been called:
it may block if all of the following are true: the shared state was created by a call to std::async, the shared state is not yet ready, and this was the last reference to the shared state.
See std::futures from std::async aren't special! for a detailed treatment of the subject.
Add these 2 lines at the end of main:
f1.wait();
f2.wait();
This will make sure the threads finish before main exists.
Based on man -S 7 signal, when a program which has not defined a signal handler receives SIGTERM, the default action is to Term.
I am registering a custom signal handler for SIGTERM, but I want the final statement (after specific cleanup is done) in my custom handler to be a function call that achieves the exact same effect as Term.
What is the correct function to call here?
I have tried exit(0), but that causes the destructors of statically initialized objects to be called, which does not match the behavior of Term. I have also tried abort(), and that causes a core dump.
In the following example, I am using the lifetime of statically allocated objects as an illustrative example, but my question is more broad than just the lifetime of statically allocated objects.
#include <stdio.h>
#include <stdlib.h>
#include <signal.h>
struct Foo{
~Foo() {
fprintf(stderr, "Dying!\n");
}
Foo() {
fprintf(stderr, "Constructing!\n");
}
};
Foo foo;
void sig_handler(int signo) {
// exit(0);
// abort();
}
int main(){
// signal(SIGTERM, sig_handler);
while(1);
}
Here are various behaviors:
The code as-is will print Constructing! but not Dying! if SIGTERM is received.
When the //signal line is commented back in, and exit(0) is commented back in, the code will print both Constructing! and Dying!
When exit(0) is commented out, and abort() is commented in, the program will output Constructing! followed by Aborted (core dumped).
To ask my question in another way, I want to know what I need to put in the body of signal_handler in order to mimic behavior 1 in every way (not just the output I have shown).
signal(SIGTERM, SIG_DFL);
kill(getpid(), SIGTERM);
There is no function call, as termination upon signals is handled by the kernel, not the user process, but this will restore the default handler, then send a signal to yourself, which kills the process just like the signal had never been caught.
You can call _exit instead of exit , which should exit the process without running global destructors.