Programming

Are there any list of function calls that should not be called in a signal handler ?
I have been thinking write () is uninterrupted until it is done - this is something new from the statement that it is ' partially ' atomic.

Is there any way I could test this behavior by some kind of simulation ?

Here is one more point / question ,
with newer signal semantics - using sigaction

kernel guarantees the binary that when executing the handler registered for a possible signal, within that block another signal of the same kind would not be delivered until it returns - in such case why shouldn't a fflush operation be used ?

Different operating systems have different implementations of functions, so it is better to err on the side of safety. It would be simpler to have a list of functions that can be called.

Also depends if you are using non-blocking IO.

Is there any way I could test this behavior by some kind of simulation ?

Here is one more point / question ,
with newer signal semantics - using sigaction

Good point, except alot of memory management his handled inside libc, not the kernel, so a signal can occur in the middle of, say, malloc or free, while the routine is updating a list of free memory pointers, if you interrupt and call in the middle another memory allocation routine you could upset the apple cart. Basically, those routines not being reentrant.

If you move onto threaded code, you don't use signal handlers at all, you use sigwait() to return you a signal once it occurs.

Thanks for all the help. I have everything working except KIll -9, But I am learning in stages thanks to you all .


questions:
1. I am still confused about using atexit(). Isn't wastefull to resources to call another function that just exits? All I need to do really is call exit(); I havent implemented logging or anything and all filehandles and kids are closed.

2. I still need to work on the printfs..I just got back from AC at 2am. Banged this out when I got back--haha.


3. "you have done sigfillset but done nothing with the sigset_t, you need to call sigprocmask to block or unblock those signals."

I am still working on this one!!

4. There has to be a way to at least know sigkill is coming so I can print before it happens. I say this because some linux distros show the sigkill or are they faking it with sigterm? I did notice sigterm and sigkill are always together.


Here is what I Have now: Feel free to critique(so I don't learn bad Habits) .

So, is flush in or out? I am thinking, I dont need it because when I exit, that should clean up right?

Code:

static struct sigaction act; 


sigemptyset (&act.sa_mask);
  act.sa_flags = 0;

  /* Register the handler for SIGINT To Ignore. */
  act.sa_handler = SIG_IGN;
  sigaction (SIGINT, &act, NULL);

  /* Register the handler for SIGHUP To Ignore */
  act.sa_handler = SIG_IGN;
  sigaction (SIGHUP, &act, NULL);


       //calls function catcher.

  /* Register the handler for SIGTERM. */
  act.sa_handler =  catcher;
  sigaction (SIGTERM, &act, 0);


  //SIGKILL CANNOT BE CAUGHT!! KILL -9
  /* Register the handler for SIGKILL. */
  act.sa_handler =  catcher;
  sigaction (SIGKILL, &act, 0);




=======================================================
//gracefully quit on sigterm and sigkill.
void catcher(int sig)
{

  printf ("Caught signal %d\n", sig);
  fflush(stdout);
  switch (sig)

   case SIGTERM:

          printf("exiting sigterm");
          exit(1);
          fflush(stdout);
          break;

        case SIGKILL:

          printf("sigkilla");
          exit(1);
          fflush(stdout);
          break;
  }
}   // end function catcher

1. "atexit" does not call exit, it installs a callback function that will be called when the process does exit.

2. exit(int) is a function that does not return, there is no point in having code following it, eg fflush().

3.remember, the code in a signal handler:

(a) just be setting variables/flags
(b) using minimal IO, write for example may be used, but nothing that uses the heap
(c) siglongjmp may be used, give that a go.....

thanks for all the help.