home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / lang / c / 11456 < prev    next >
Encoding:
Internet Message Format  |  1992-07-22  |  3.0 KB
  1. Path: sparky!uunet!mcsun!fuug!demos!kiae!glas!demos!mdd.comm.mot.com!mitchell
  2. From: mitchell@mdd.comm.mot.com
  3. Newsgroups: comp.lang.c
  4. Date: 17 Jul 92 18:12 MDT
  5. Subject: Re: trapping "control C"
  6. Sender: Notesfile to Usenet Gateway <notes@glas.apc.org>
  7. Message-ID: <1992Jul17.141248.4837@mdd.comm.m>
  8. References: <13t9osINNqam@darkstar.ucsc.edu>
  9. Nf-ID: #R:13t9osINNqam@darkstar.ucsc.edu:-1109617974:1992Jul17.141248.4837@mdd.comm.m:-1220607600:001:2554
  10. Nf-From: mdd.comm.mot.com!mitchell    Jul 17 18:12:00 1992
  11. Lines: 74
  12.  
  13.  
  14. in comp.lang.c, dylan@ibmpcug.co.uk (Matthew Farwell) said:
  15.  
  16. >In article <13t9osINNqam@darkstar.UCSC.EDU> gil@cse.ucsc.edu (Elmer Fudd) writes:
  17. >>can anyone suggest where i can get info/examples on how to trap a
  18. >>control C in a program?
  19. >>[...]
  20. >
  21. >In most cases, using signal() to trap a SIGINT will do what you
  22. >want it to do.  But again, this is machine dependent - under Unix you
  23. >can set the interupt key to be whatever you want (mine is currently set
  24. >to DEL, not CTRL C).
  25. >
  26. >However, here is some code which will probably do what you want it to
  27. >do...
  28. >
  29. >#include <stdio.h>
  30. >#include <stdlib.h>
  31. >#include <signal.h>
  32. >
  33. >void handler()
  34. >{
  35. >    fprintf(stderr, "got a SIGINT. Exiting.\n");
  36. >
  37. >    /* do some cleanup */
  38. >
  39. >    exit(1);
  40. >}
  41. >
  42. >int main()
  43. >{
  44. >    if (signal(SIGINT, SIG_IGN) != SIG_IGN)
  45. >        signal(SIGINT, handler);
  46. >
  47. >    while (1) printf("Output\n");    /* loop endlessly */
  48. >
  49. >    /* NOTREACHED */
  50. >
  51. >    return 0;    /* for gcc -Wall */
  52. >}
  53. >
  54.  
  55. Having been recently bitten by a signal handler, I thought I'd comment here.
  56.  
  57. Looking in PJP's "The Standard C Library", chapter 9, I see that he goes on
  58. at some length about syncronization and other problems which can occur in
  59. handling signals.  In part, he says:
  60.  
  61.   The occurence of a signal introduces a second thread of control within
  62.   a program.  That raises all sorts of issues about syncronization and
  63.   reliable operation.  The C Standard promises little in either regard.
  64.   C programs have been handling signals since the earliest days of the
  65.   language.  Nevertheless, a portable program can safely take very few
  66.   actions within a signal handler.
  67.  
  68. The case above is pretty vanilla, except for the as-yet undefined cleanup,
  69. since the program terminates from within the handler.  If the handler
  70. didn't terminate, it would have to be very careful about what actions
  71. it took.  The safest approach I know is to do _NOTHING_ inside the handler
  72. except to set a global variable to indicate that the signal occurred, and
  73. place code to test that variable and react to the signal in the mainline
  74. control thread.  PJP points out that even this is not necessarily 100%
  75. bulletproof.  It's generally a good idea, however, to do as little as
  76. possible in a signal handler.
  77.  
  78. I think it's also a good idea to make that a stylistic habit, and extend the
  79. maxim of doing as little as possible with a signal handler even to handlers
  80. which could terminate the program from within the handler control thread.
  81. Set a flag and return.  React to the flag in the mainline control thread.
  82.  
  83. -- 
  84. mitchell@mdd.comm.mot.com (Bill Mitchell)
  85.  
  86.  
  87.