Object-level signal delivery

[lpw]

I have dilligently reviewed FAQ-lite Section 3.2, "How do I pass a
pointer-to-member-function to a signal handler, X event callback, system
call that starts a thread/task, etc." The only suggestion on how to deliver
a signal to an object is to do it via a global variable and a wrapper
function, a technique that is generally a Bad Idea (due to the usage of a
global variable). I understand that this ng is dedicated to the discussion
of platform-independent C++ issues, and that signals are primarily an
artifact of UNIX. My question is, however, more related to the proper way
of structuring my C++ code rather than the specifics of signal handling.
I've been racking my brain on how to incorporate signal handling into my C++
programs whilst remaining one with the OO nature. I would like to propose a
possible solution, one that, IMHO, is a little cleaner and fits better with
the OO paradigm than simply using global object pointers.

Suppose that we have a program that does a lot of I/O (sockets, pipes,
files, etc.). For each I/O "stream", we have a dedicated handler object.
When the user becomes bored and sends SIGINT to our program, we would like
all our handlers to cleanly close their respective TCP connections, IPC
pipes, etc. With things like connection-oriented sockets, this is often
more involved than merely calling close(). The responsibility to cleanly
shut down a particular I/O "stream" should be delegated to that stream's
handler object. Thus, we need object-level signal delivery to a number of
heterogeneous objects. This can be accomplished by having all those objects
derive from a common base class. The responsibility of that class (let's
call it Interruptible) is to maintain a list of all live Interruptible
objects and invoke the signal handlers of those objects whenever SIGINT is
caught. The code below illustrates this paradigm using a silly Runner class
instead of an I/O handler. But the idea remains the same.

#include <iostream>
#include <string>
#include <list>
#include <cstdlib>
#include <ctime>
#include <signal.h>
#include <unistd.h>

using namespace std;

class Interruptible {

// "global" list of live interruptible objects
static list<Interruptible*> instances;

protected:

// all interruptible classes must implement this method
virtual void sigint_handler() = 0;

Interruptible() {
// add me to global list of live interruptible objects
instances.push_back(this);
}

virtual ~Interruptible() {
// remove me from global list of live interruptible objects
instances.remove(this);
}

public:

// the "global" signal handler
static void sigint_handler(int s) {
// call all interruptible objects
list<Interruptible*>::const_iterator i;
for (i=instances.begin(); i!=instances.end(); i++)
(*i)->sigint_handler();
// goodbye
exit(0);
}
};

list<Interruptible*> Interruptible::instances;

class Runner : public Interruptible {

string name;

virtual void sigint_handler() {
cout << name << " got SIGINT " << endl;
//
// do some cleanup here
//
}

public:

Runner(const string& str) : Interruptible(), name(str) { }

void run() {
cout << name << " is running" << endl;
//
// do something smart and useful here
//
sleep(1+rand()&3);
}
};

int main(void) {

signal(SIGINT, Interruptible::sigint_handler);

srand(time(NULL));

Runner obj1("Runner 1");
Runner obj2("Runner 2");

while (true) {
obj1.run();
obj2.run();
}
}


I am most keen on receiving your comments, questions, flames, death threats,
and/or suggestions on the proposed solution. Again, I am more interested in
writing good object-oriented C++ code rather than the platform specific
mechanisms of signal delivery. I would love to hear of other possible
approaches. Just please don't say that this is completely off topic.

 

[Jim Langston]

I have dilligently reviewed FAQ-lite Section 3.2, "How do I pass a
pointer-to-member-function to a signal handler, X event callback, system
call that starts a thread/task, etc." The only suggestion on how to
deliver
a signal to an object is to do it via a global variable and a wrapper
function, a technique that is generally a Bad Idea (due to the usage of a
global variable). I understand that this ng is dedicated to the
discussion
of platform-independent C++ issues, and that signals are primarily an
artifact of UNIX. My question is, however, more related to the proper way
of structuring my C++ code rather than the specifics of signal handling.
I've been racking my brain on how to incorporate signal handling into my
C++
programs whilst remaining one with the OO nature. I would like to propose
a
possible solution, one that, IMHO, is a little cleaner and fits better
with
the OO paradigm than simply using global object pointers.

Suppose that we have a program that does a lot of I/O (sockets, pipes,
files, etc.). For each I/O "stream", we have a dedicated handler object.
When the user becomes bored and sends SIGINT to our program, we would
like
all our handlers to cleanly close their respective TCP connections, IPC
pipes, etc. With things like connection-oriented sockets, this is often
more involved than merely calling close(). The responsibility to cleanly
shut down a particular I/O "stream" should be delegated to that stream's
handler object. Thus, we need object-level signal delivery to a number of
heterogeneous objects. This can be accomplished by having all those
objects
derive from a common base class. The responsibility of that class (let's
call it Interruptible) is to maintain a list of all live Interruptible
objects and invoke the signal handlers of those objects whenever SIGINT is
caught. The code below illustrates this paradigm using a silly Runner
class
instead of an I/O handler. But the idea remains the same.

#include <iostream>
#include <string>
#include <list>
#include <cstdlib>
#include <ctime>
#include <signal.h>
#include <unistd.h>

using namespace std;

class Interruptible {

// "global" list of live interruptible objects
static list<Interruptible*> instances;

protected:

// all interruptible classes must implement this method
virtual void sigint_handler() = 0;

Interruptible() {
// add me to global list of live interruptible objects
instances.push_back(this);
}

virtual ~Interruptible() {
// remove me from global list of live interruptible objects
instances.remove(this);
}

public:

// the "global" signal handler
static void sigint_handler(int s) {
// call all interruptible objects
list<Interruptible*>::const_iterator i;
for (i=instances.begin(); i!=instances.end(); i++)
(*i)->sigint_handler();
// goodbye
exit(0);
}
};

list<Interruptible*> Interruptible::instances;

class Runner : public Interruptible {

string name;

virtual void sigint_handler() {
cout << name << " got SIGINT " << endl;
//
// do some cleanup here
//
}

public:

Runner(const string& str) : Interruptible(), name(str) { }

void run() {
cout << name << " is running" << endl;
//
// do something smart and useful here
//
sleep(1+rand()&3);
}
};

int main(void) {

signal(SIGINT, Interruptible::sigint_handler);

srand(time(NULL));

Runner obj1("Runner 1");
Runner obj2("Runner 2");

while (true) {
obj1.run();
obj2.run();
}
}


I am most keen on receiving your comments, questions, flames, death
threats,
and/or suggestions on the proposed solution. Again, I am more interested
in
writing good object-oriented C++ code rather than the platform specific
mechanisms of signal delivery. I would love to hear of other possible
approaches. Just please don't say that this is completely off topic.

Your problem is going to deal with you not having any form of locking.
Consider your statement:
for (i=instances.begin(); i!=instances.end(); i++)
(*i)->sigint_handler();

What happens when this is running in one thread, and some other thread is
pushing opjects onto the list? I.E. Somewhere you've called sigint_handler
while at the same time some thread is creating a derived of Interruptible.

In your current program this doesn't seem to be a problem as you don't have
any threads creating other threads, but other cases you may want to do that.

 

[werasm]

I have dilligently reviewed FAQ-lite Section 3.2, "How do I pass a
pointer-to-member-function to a signal handler, X event callback, system
call that starts a thread/task, etc."

I have done something similar. We use it as architecture for our
Multitasking projects. Basically it boils down to passing callback
wrappers over an associated queue (or server). All the concurrent (or
psuedo concurrent) threads/task consist of a handler that blocks on a
queue (also known as mailbox) expecting callback wrapper bases only
(use encapsulating teqniques that prevent any thing else from being
sent over mailbox). The callback is then executed on receipt, upon
whereafter the wrapper is destroyed and the queue is monitored again.
It gets interesting - wrappers that handle member functions with
arguments, what if class instances don't exist when the delayed member
function call is made, etc.

It is a kind of nice pattern though, because it allows for marrying OOP
with multitasking, almost abstracting the multitasking from the OOP
specialist.

The only suggestion on how to deliver
a signal to an object is to do it via a global variable and a wrapper
function, a technique that is generally a Bad Idea (due to the usage of a
global variable).

Obviously a global variable is not needed to deliver a wrapper to a
"Worker Thread". Encapsulation can be used - the thread is then
wrapped. Most threads allow arguments on their entry points - an
argument can be the pointer to an object associated with that
particular object. The entry point to the tread itself being a static
member function, therefore having access to instance internals (and
it's associated mailbox).

Point is global variables are not the only way.

I understand that this ng is dedicated to the discussion
of platform-independent C++ issues, and that signals are primarily an
artifact of UNIX. My question is, however, more related to the proper way
of structuring my C++ code rather than the specifics of signal handling.

I don't know about signals, but you can certainly wrap member
functions, and access them in the context associated with a particular
object - if you want to only associate an object with one context.

I've been racking my brain on how to incorporate signal handling into my C++
programs whilst remaining one with the OO nature. I would like to propose a
possible solution, one that, IMHO, is a little cleaner and fits better with
the OO paradigm than simply using global object pointers.

Who ever used global object pointers?

I think I have done something that

Suppose that we have a program that does a lot of I/O (sockets, pipes,
files, etc.). For each I/O "stream", we have a dedicated handler object.
When the user becomes bored and sends SIGINT to our program, we would like
all our handlers to cleanly close their respective TCP connections, IPC
pipes, etc.

I don't think a sigint is required to do this. Using queueing
mechanisms, finishing the current job at hand and then fetching the
next request from a queue should work? IMHO that's the more OO
approach. I've used these types of approaches for comms (TCP/IP).

With things like connection-oriented sockets, this is often
more involved than merely calling close(). The responsibility to cleanly
shut down a particular I/O "stream" should be delegated to that stream's
handler object. Thus, we need object-level signal delivery to a number of
heterogeneous objects. This can be accomplished by having all those objects
derive from a common base class. The responsibility of that class (let's
call it Interruptible) is to maintain a list of all live Interruptible
objects and invoke the signal handlers of those objects whenever SIGINT is
caught.

In who's context does the interruptible object normally execute. In
which context does the sigint handler execute. How does these contexts
influence each other? Sigint handler seems to be in an orthogonal
context in your example.

The code below illustrates this paradigm using a silly Runner class
instead of an I/O handler. But the idea remains the same.

#include <iostream>
#include <string>
#include <list>
#include <cstdlib>
#include <ctime>
#include <signal.h>
#include <unistd.h>

using namespace std;

class Interruptible {

// "global" list of live interruptible objects
static list<Interruptible*> instances;

protected:

// all interruptible classes must implement this method
virtual void sigint_handler() = 0;

Interruptible() {
// add me to global list of live interruptible objects
instances.push_back(this);
}

virtual ~Interruptible() {
// remove me from global list of live interruptible objects
instances.remove(this);
}

public:

// the "global" signal handler
static void sigint_handler(int s) {
// call all interruptible objects
list<Interruptible*>::const_iterator i;
for (i=instances.begin(); i!=instances.end(); i++)
(*i)->sigint_handler();
// goodbye
exit(0);
}
};

list<Interruptible*> Interruptible::instances;

class Runner : public Interruptible {

string name;

virtual void sigint_handler() {
cout << name << " got SIGINT " << endl;
//
// do some cleanup here
//
}

public:

Runner(const string& str) : Interruptible(), name(str) { }

void run() {
cout << name << " is running" << endl;
//
// do something smart and useful here
//
sleep(1+rand()&3);
}
};

int main(void) {

signal(SIGINT, Interruptible::sigint_handler);

srand(time(NULL));

Runner obj1("Runner 1");
Runner obj2("Runner 2");

while (true) {
obj1.run();
obj2.run();
}
}


I am most keen on receiving your comments, questions, flames, death threats,
and/or suggestions on the proposed solution. Again, I am more interested in
writing good object-oriented C++ code rather than the platform specific
mechanisms of signal delivery.

We use the command pattern for this. We pass commands (encapsulating
member function pointers and their receivers) between threads using
queues. I have not seen this technique before . But maybe I have not
looked enough. A lot of work because you need to build the architecture
- not OS specific, using the bridge pattern, mostly. Has some problems
of itself, but I think they can be overcome - especially now since
boost has arrived. Is this what you had in mind? Communication between
threads in an OO way?

Regards,

W