marwk@levels.sait.edu.au (01/01/91)
In the TURBO C 2.0 reference manual on page 346 thre is an example of using
signal() to divert the CTRL-BREAK exception to a user-defined routine.
I entered the following code and it works the first time that ^Break is
pressed, but then the program aborts the next time I press ^Break again.
Does the signal get used up each time it is used?
#include <stdio.h>
#include <signal.h>
#include <conio.h>
void gotcha(int sig)
{
printf("Ctrl-Break has been disabled - Press any key to continue\n");
fflush(stdin);
getch();
}
void main(void)
{
signal(SIGINT, gotcha);
printf("OK, go on, just you try to interrupt me!\n");
while (1)
printf("a");
}
Thank you.
Rayjohnm@cory.Berkeley.EDU (John D. Mitchell) (01/01/91)
n article <15794.277f7a95@levels.sait.edu.au> marwk@levels.sait.edu.au writes: >In the TURBO C 2.0 reference manual on page 346 thre is an example of using >signal() to divert the CTRL-BREAK exception to a user-defined routine. >I entered the following code and it works the first time that ^Break is >pressed, but then the program aborts the next time I press ^Break again. >Does the signal get used up each time it is used? [code example deleted] Yep. TC follows the SystemV style signal behavior. Therefore you need to call signal again in the handler function to handle multiple signals. I prefer the BSD-like behavior. Good luck, John D. Mitchell johnm@cory.Berkeley.EDU
marwk@levels.sait.edu.au (01/01/91)
In article <9975@pasteur.Berkeley.EDU>, johnm@cory.Berkeley.EDU (John D. Mitchell) writes: > n article <15794.277f7a95@levels.sait.edu.au> marwk@levels.sait.edu.au writes: >>In the TURBO C 2.0 reference manual on page 346 thre is an example of using >>signal() to divert the CTRL-BREAK exception to a user-defined routine. >>I entered the following code and it works the first time that ^Break is >>pressed, but then the program aborts the next time I press ^Break again. >>Does the signal get used up each time it is used? > [code example deleted] > > Yep. TC follows the SystemV style signal behavior. Therefore you > need to call signal again in the handler function to handle multiple > signals. I prefer the BSD-like behavior. > > Thank you for this information. If signal is called again in the handler function up to about 25 attempts to Break the program are successfully thwarted, but then , that's right, nothing happens - a cold boot is required. Is this to be expected, or should I replace the interrupt and forget about signals for multiple 'entraption'? Ray
johnm@cory.Berkeley.EDU (John D. Mitchell) (01/02/91)
In article <15795.2780a5d4@levels.sait.edu.au> marwk@levels.sait.edu.au writes: [...Yep, stuff deleted...] >If signal is called again in the handler function up to about 25 attempts >to Break the program are successfully thwarted, but then , that's right, >nothing happens - a cold boot is required. Are you saying that the system goes into La-La-Land after 25 total break requests or if there are 25 levels of nesting break requests? ----- John D. Mitchell johnm@cory.Berkeley.EDU P.S. This thread should probably be moved to one of the PC groups or to e-mail.
wirzeniu@cs.Helsinki.FI (Lars Wirzenius) (01/03/91)
In article <15795.2780a5d4@levels.sait.edu.au> marwk@levels.sait.edu.au writes: >If signal is called again in the handler function up to about 25 attempts >to Break the program are successfully thwarted, but then , that's right, >nothing happens - a cold boot is required. I *could* be due to the call to printf in the signal handler. Remember, there's little you can *realiably* do in a signal handler, just about the only thing is setting a flag. Lars Wirzenius wirzeniu@cs.helsinki.fi wirzenius@cc.helsinki.fi
madams@ecst.csuchico.edu (Michael E. Adams) (01/03/91)
>there's little you can *realiably* do in a signal handler, just about >the only thing is setting a flag. > >Lars Wirzenius Your a little off base here. DOS reentrance is not a problem when servicing int 23h. The default handler from signal(SIGINT, func); is int 23h, however within the scope of your program you can define func to be an alternate Ctrl-C handler! func can, but does not need to return to DOS, it can be as robust as needed. "While in a Ctrl-C/Ctrl-Break handler, you can use any DOS function needed to process the condition." DOS Programmer's Reference, 2nd Edition by Terry Dettmann (w/ 2nd Ed. revisions by Jim Kyle) Published by QUE (C) 1989 ISBN:0-88022-458-4 Also see MS 'C' 5.1 run-time library ref, pg. 543 for an example of printf used with a Ctrl-C signal. However Lars, you are quite correct about other types of int handlers needing to be cautious about what DOS funtions they use. It just happens that int 23h is "defined" to be a special case! :-) Hope this makes things a little more confusing! ;-) (___) | Michael E. Adams (o o) | Custom Computer Programming /-------\ / | P.O. Box 5027 / | ||O | Chico, California 95927-5025 U.S.A. * ||,---|| | ~~ ~~ | internet: madams@cscihp.ecst.csuchico.edu No BULL bandwidth |
wirzeniu@cs.Helsinki.FI (Lars Wirzenius) (01/04/91)
In article <1991Jan03.113611.4796@ecst.csuchico.edu> madams@ecst.csuchico.edu (Michael E. Adams) writes: >Your a little off base here. DOS reentrance is not a problem when >servicing int 23h. The default handler from signal(SIGINT, func); I wasn't talking about that, however. The C library itself (printf being the particular case) need not be reentrant: it might use static data structures etc. This has nothing to do with MS-DOS specifically, it's just as true for UNIX and other environments with implementations of the C language. I have been unable to recreate the problem with the program crashing after about 25 interruptions. Maybe the problem lies elsewhere after all? Lars Wirzenius wirzeniu@cs.helsinki.fi wirzenius@cc.helsinki.fi