Click to See Complete Forum and Search --> : Catching signals with a class member
Bradmont5
04-04-2002, 02:32 AM
I've been doing some programming on a network daemon, and I've realised that I need to catch SIGPIPE in case a client disconnects improperly... Now, the problem lies in the fact that my daemon(s) is/are a class, and I need to close the sockets properly when I get the signal, so I want to use one of the class's methods when the signal is caught -- but I can't pass a function pointer to the class method -- is there any, say, C++ library for signal handling to get around this? Or some good/standard/well known way to deal with it?
Thanks a bunch.
marvin
04-04-2002, 07:04 AM
I remember reading this page (http://www.parashift.com/c++-faq-lite/pointers-to-members.html#faq-30.2) when I was dealing with a pointer to a member function... Maybe the method suggested on that page is a possible work around for you? They use a wrapper function as signal handler and this function calls a member function using a global object.
Bradmont5
04-04-2002, 05:29 PM
I was thinking of that, but it won't work, since there's going to be multiple instances of the class, so a single global object wouldn't work -- and a global vector (or similar) wouldn't likely work either, since the handler needs to know from which object the signal originated...
marvin
04-04-2002, 05:57 PM
Ok. I don't know of a way to get the signal handler know which instance of the class caused the signal.
Can't you just disable the SIGPIPE signal and do some extra error checking when reading and writing to the pipe? The man page for write(2) says
ERRORS
<snip>
EPIPE fd is connected to a pipe or socket whose reading end is closed. When this happens the writing process will receive a SIGPIPE signal; if it catches, blocks or ignores this the error EPIPE is returned.
Don't know if this method is possible for you since you will not find out about the error until you actually try to read/write from/to it.
Bradmont5
04-04-2002, 06:10 PM
hmm... when the signal handler exits, it returns to the function from which the signal came, right? Could I have the signal handler throw an exception and then catch that back in the function doing the network communication?
Bradmont5
04-04-2002, 06:53 PM
hmm... that doesn't work...
If I were to set up the daemon to drop sigpipes, how would I go about detecting a lost connection from a client?
marvin
04-04-2002, 07:18 PM
I've been thinking some more... is the SIGPIPE sent unless you actually try to read or write to the closed socket/pipe? If it is not, there should be no problem since you will catch the error when doing the error checking after a read or write.
Bradmont5
04-05-2002, 01:36 AM
ok, I got it working -- what I did was check if send or recv ever returned -1, meaning an error, and acted apropos.