The code I'm working with has a shared signal handler that switches on the signal number to handle it appropriately.
I'm adding a custom signal. Something like this
static void signal_handler (int s)
{
if ( s == SIGTERM ) clean_up () ;
else if ( s == SIGRTMIN+1 ) ; // do nothing
}
SIGRTMIN and SIGRTMAX are #defines of function calls which initialize static data (in the implementations I've seen on google code search)
Signal handlers are supposed to be non-reentrant. Does the use of static data in the accessor to SIGRTMIN and SIGRTMAX make these macros unsafe to use in a signal handler?
I don't know what implementation you are smoking, but in libc those functions seem to simply return a constant static variable most of the time.
You are right, there is a possible race between the two calls to init(), but that simply just initializes a static int twice to the same constant, hardly a worry.
And, while the static variable is not really that constant, they tell you to only modify said variable at the start of your program(and I think only pthread really modifies it that much).
So no need to worry about these functions(from allocrtsig.c glibc 2.14).
And, if you are really worried, just call SIGRTMIN once before you bind the signal handler. That will get the init() function out of the way.
/* Return number of available real-time signal with highest priority. */
int __libc_current_sigrtmin (void)
{
#ifdef __SIGRTMIN
if (!initialized)
init ();
#endif
return current_rtmin;
}
libc_hidden_def (__libc_current_sigrtmin)
/* Return number of available real-time signal with lowest priority. */
int __libc_current_sigrtmax (void)
{
#ifdef __SIGRTMIN
if (!initialized)
init ();
#endif
return current_rtmax;
}
libc_hidden_def (__libc_current_sigrtmax)
Related
Is there a way to construct a class with specific parameters in a separate thread?
In the examples I have seen I can only see thread running functions and member functions. To be more specific, I would need it to run this constructor in a separate thread:
Thermistor(ukd_Adc * pAdc,
const lookup_table_t * pLUT,
uint8_t numOfLutElements);
I want to construct the class in a different thread to assert functionality and check for edge cases.
If there is an edge case like the pointer to ukd_Adc being NULL, the assert will make it hang in an infinite loop. This thread will allow me to set a time limit on how long the constructor may run so it does not go into an infinite loop.
This is for testing purposes since google test does not have a timeout feature to my knowledge.
If you simply want to construct an object on a separate thread and check if it has successfully finished within a specific time constrain, use:
int main() {
std::promise<std::shared_ptr<Thermistor>> promise;
std::future<std::shared_ptr<Thermistor>> future = promise.get_future();
std::thread([&promise](ukd_Adc * pAdc,
const lookup_table_t * pLUT,
uint8_t numOfLutElements) {
promise.set_value_at_thread_exit(std::make_shared<Thermistor>(pAdc, pLUT, numOfLutElements));
}, <pAdc-value>, <pLUT-value>, <numOfLutElements-value>).detach();
auto status = future.wait_for(std::chrono::seconds(3));
if (status == std::future_status::ready)
{
// succeeded
}
else
{
// failed
}
}
You can use the alarm() function to raise a signal (SIGALRM) after a specified amount of time:
static bool alarmed = false;
extern "C" void handler(int signo)
{
alarmed = true;
}
signal(SIGALRM, handler);
alarm(5); // seconds to SIGALRM
// do stuff
// if (alarmed) ...
You could use pthreads start the process and when you don't like your thread anymore you can kill it off with pthread_cancel
pseudo code
start thread
wait
cancel thread if not finished
I am doing a kind of shell: depending of the user's entry, I must call some function. I cannot modify the content of those called functions since my program is only a client and has no visibility of them.
But I want the possibility for the user to kill the call using CTRL+C. Here is the minimal code:
#include <csignal>
#include <iostream>
#include <unistd.h>
void do_thing(void)
{
std::cout << "entering in do_thing()\n";
while(42)
::sleep(1);
}
extern "C" {
void signal_handler(int);
}
class Shell
{
friend void signal_handler(int);
public:
static Shell & Instance(void)
{
static Shell instance;
return instance;
}
int run(void)
{
std::string buff;
while ((std::cin >> buff))
{
if (buff == "foo")
do_thing(); // this must be terminable
else
std::cout << "(nothing)\n";
}
return 0;
}
private:
Shell(void)
{
::signal(SIGINT, signal_handler);
}
void signal(int sig)
{
if (sig == SIGINT)
;// must terminal the function call
}
};
extern "C" {
void signal_handler(int sig)
{
Shell::Instance().signal(sig);
}
}
int main(void)
{
return Shell::Instance().run();
}
I considered three possibilities:
I tried to create a thread class derived from std::thread, with a kill() method that throws an exception. The function call is in a try-catch block. It works, but this is a bad solution since the destructor cannot be called, and the resource is never freed.
I considered using fork, but I think it is an overkill to just get the possibility of interrupt a function call.
I tried to throw an exception from the signal handler, but I saw that this is a bad idea since this is very compiler/OS dependent code.
How could you do the thing? What is the better solution?
Note: I deleted the old post because it was close requested, and took into consideration the C/C++ tags.
Essentially, no, there is no standard why to interrupt a thread in C++. Threads run co-operatively and as such, they need to "give up" control.
If the code for do_thing were modifiable, then you can create a flag (atomic) to signal that the thread should give up and exit. This can be periodically checked by the thread and complete as required.
Given the code for do_thing is not modifiable, there is a small window of opportunity that can be used to "kill" or "cancel" the thread (albeit it won't be "standard" and support will be limited to targeted platforms).
std::thread offers a function to retrieve a native_handle() that is implementation defined. Once obtained (and converted), it can be used to kill or cancel the thread.
If pthreads are being used, see pthread_kill (or pthread_cancel if supported by the target thread).
On windows, see the TerminateThread function.
Be warned; aside from the platform specific code required, the thread terminations generally leave the objects on that thread in "limbo" and with them, the resources they control.
In C++11, what is the safest (and perferrably most efficient) way to execute unsafe code on a signal being caught, given a type of request-loop (as part of a web request loop)? For example, on catching a SIGUSR1 from a linux command line: kill -30 <process pid>
It is acceptable for the 'unsafe code' to be run on the next request being fired, and no information is lost if the signal is fired multiple times before the unsafe code is run.
For example, my current code is:
static bool globalFlag = false;
void signalHandler(int sig_num, siginfo_t * info, void * context) {
globalFlag = true;
}
void doUnsafeThings() {
// thigns like std::vector push_back, new char[1024], set global vars, etc.
}
void doRegularThings() {
// read filesystem, read global variables, etc.
}
void main(void) {
// set up signal handler (for SIGUSR1) ...
struct sigaction sigact;
sigact.sa_sigaction = onSyncSignal;
sigact.sa_flags = SA_RESTART | SA_SIGINFO;
sigaction(SIGUSR1, &sigact, (struct sigaction *)NULL);
// main loop ...
while(acceptMoreRequests()) { // blocks until new request received
if (globalFlag) {
globalFlag = false;
doUnsafeThings();
}
doRegularThings();
}
}
where I know there could be problems in the main loop testing+setting the globalFlag boolean.
Edit: The if (globalFlag) test will be run in a fairly tight loop, and an 'occasional' false negative is acceptable. However, I suspect there's no optimisation over Basile Starynkevitch's solution anyway?
You should declare your flag
static volatile sig_atomic_t globalFlag = 0;
See e.g. sig_atomic_t, this question and don't forget the volatile qualifier. (It may have been spelled sigatomic_t for C).
On Linux (specifically) you could use signalfd(2) to get a filedescriptor for the signal, and that fd can be poll(2)-ed by your event loop.
Some event loop libraries (libevent, libev ...) know how to handle signals.
And there is also the trick of setting up a pipe (see pipe(2) and pipe(7) for more) at initialization, and just write(2)-ing some byte on it in the signal handler. The event loop would poll and read that pipe. Such a trick is recommended by Qt.
Read also signal(7) and signal-safety(7) (it explains what are the limited set of functions or syscalls usable inside a signal handler)....
BTW, correctness is more important than efficiency. In general, you get few signals (e.g. most programs get a signal once every second at most, not every millisecond).
Does the signal() function overwrite other signal calls a process might have set up? I.e. if a SIGINT handler has been setup by a process, and a DLL calls signal(SIGINT,xxx) to handle its own termination code, does the original SIGINT handler get disabled?
The signal() call:
Installs the handler you specify as a new signal handler, and
Tells you what the old handler was.
The new handler will be called instead of the old one. If you want to chain them, you need to do something like:
typedef void (*Handler)(int signum);
static Handler old_int_handler = SIG_IGN;
static void int_handler(int signum) /* New signal handler */
{
/* ...do your signal handling... */
if (old_int_handler != SIG_IGN && old_int_handler != SIG_DFL)
(*old_int_handler)(signum);
}
static void set_int_handler(void) /* Install new handler */
{
Handler old = signal(SIGINT, SIG_IGN);
if (old != SIG_IGN)
{
old_int_handler = old;
signal(SIGINT, int_handler);
}
}
static void rst_int_handler(void) /* Restore original handler */
{
Handler old = signal(SIGINT, SIG_IGN);
if (old == int_handler)
{
signal(SIGINT, old_int_handler);
old_int_handler = SIG_IGN;
}
}
void another_function()
{
/* ... */
set_int_handler();
/* ... */
rst_int_handler();
/* ... */
}
If interrupts were being ignored, this keeps them ignored. If interrupts were being handled by a user-defined interrupt handler, then this calls your signal handling code and the original signal handling code.
Note that the advice from Christian.K about not handling signals in a DLL (shared library) is also relevant and valid. The description above assumes you decide to ignore that advice.
This is not a "literal" answer to your question, but a recommendation: You shouldn't do this in a DLL.
It is unexpected and often annoying for the application that uses the DLL. A DLL should (normally) be "passive" and only provide functions for the application to call.
So rather provide a public function from your DLL that applications are required to call e.g. MyDllCleanup(). Then let the application decide how it calls that function (via a signal handler or other). BTW, the same goes for initialization: rather than relying on DllMain (or _init/_fini with libdl on UNIX) provide explicit functions for applications to call.
Maybe there is a really simple solution for my problem, but I'm really confused with all the boosts around me.
Here's my problem:
I want to start a task (calculation, file system operations, etc.), raised by a callback system which calls the CallbackReceived function and I want to pass this operation to a thread, typically represented by a member function of an object. The thread isn't guaranteed to finish, so it should have something to cancel it after some time.
Something like (don't know if this is 100% correct):
// ...
MyObject object;
// ...
void CallbackReceived(int parameter) {
boost::thread tThread(&MyObject::calculate, *&object);
boost::asio::deadline_timer tDeadlineTimer(_ioService, boost::posix_time::seconds(2));
tDeadlineTimer.async_wait(boost::bind(DeadlineTimeOut, boost::asio::placeholders::error));
tThread.join();
}
Basically, a tThread.join()` waits for the return of the thread. While waiting, my main could not receive any callbacks that may come in because it's blocked and sleeps.
So what can one do, to run the thread and not to block the calling initial program while executing the operation?
You can call join just when you need the result of the calculations.
Something like "Future" pattern. Anyway, you would have to make your thread variable global to the CallBackRecieved function (You can write some wrapper).
Note: you can call join, when thread finished its' work - nothing will be blocked.
What do you want to do with the result of calculate?
Your main thread is blocked in the .join().
If you want to handle other callbacks, you have to return to the normal execution flow, waiting for another call.
Then you have to ask yourself what do you do with the result of calculate when it's finished. Maybe the thread can put the result in a shared resource somewhere and finish gracefully.
You must first sort out all what your code is supposed to do ( processing callbacks, starting threads, what to do with the result ) then you can think of implementing it. There are new constructs in boost and C++11 called promise and future that could suit you but first you have to think about what you want.
Actually you could call the callback while your main thread is sleeping. It would just run on the context (stack) of your thread.
You probably don't want to call join at the point you are at but later or never.
Example (pseudocode):
class Worker {
void doWork(void * mainthread){
Main* main = static_cast<Main*>(mainthread);
while(hasWorkTodo){
//work
//inform main
main->callbackwithinformation(information);
}
}
class Main{
atomi_int filesfound;
void main_part(){
//start worker
boost::thread thread(&Worker::doWork, &object, this);
while(hasworktodo){
//do work
//use filesfound here
}
//About to finish make sure we join our thread
thread.join();
}
void callbackwithinformation(int updatedcount){
//here we set a flag or pass some object
//probably will need an atomic operation
filesfound = updatedcount;
}
}
You would define the implementations in cpp and the interface in a h file so no circular dependency would arise, since you are only using Main as a argument in the interface a forward declaration would suffice.
//worker.h
class mainthread;
class Worker {
void doWork(void * mainthread);
}
//worker.cpp
#include "main.h"
void Worker::doWork(/* and so on*/}
//main.h
class Main{
atomi_int filesfound;
void main_part();
void callbackwithinformation(int updatedcount);
}
//main.cpp
//no need for worker.h here
void Main::main_part() /* implementation and so on */