blog: C++/Unix

July 24, 2003

C++/Unix

While working on my gSoap Web Service program, I came across a weirditie (If Bush can make up words, so can I) of C++/Unix programming. If you set a signal handler and then catch the signal, you need to reset the handler to catch further signals.

In my case, if a client application is communication with my server (via SOAP) and the client application exits, the server will receive a broken pipe signal. This signal is sent when a program tries to write to a socket or pipe when no one is reading. So I had set my handler:

signal(SIGPIPE, my_handler);
....
void my_handler(int x) 
{
   cout << "howdy: " << x << endl;
}

And I would get the howdy: 13 notice after the client exited. And when the client would restart and exit again, the server would go down.

I think it's silly that you have to tell the system that you want to catch the same signal again. Now my handler looks like this:

void my_handler(int x)
{
  signal(SIGPIPE, my_handler); 
  return;
}

Posted by Sam at July 24, 2003 2:15 PM | TrackBack

Comments

Perhaps reading the man man page would help:

PORTABILITY
The original Unix signal() would reset the handler to SIG_DFL, and System V (and the Linux kernel and libc4,5) does the same. On the other hand, BSD does not reset the handler, but blocks new instances of this signal from occurring during a call of the handler. The glibc2 library follows the BSD behaviour.
...
...
Trying to change the semantics of this call using defines and includes is not a good idea. It is better to avoid signal altogether, and use sigaction(2) instead.

Posted by: Big Bro at July 24, 2003 2:39 PM