communication.
This braindead use of SIGINT causes problem when a frontend is
interrupted with Ctrl-C: if gnushogi is waiting for input, it would
enter a tight loop trying to read stdin, eating 100% CPU.
#endif
}
- signal(SIGINT, TerminateSearch);
+ signal(SIGUSR1, TerminateSearch);
}
if (XSHOGI)
{
- signal(SIGINT, TerminateSearch);
+ signal(SIGUSR1, TerminateSearch);
TCmoves = 40;
TCminutes = 5;
TimeControl.moves[black], TimeControl.clock[black] / 100,
TCadd/100, MaxSearchDepth);
- signal(SIGINT, Raw_TerminateSearch);
- signal(SIGQUIT, Raw_TerminateSearch);
+ signal(SIGUSR1, Raw_TerminateSearch);
}
void
Raw_SearchStartStuff(short side)
{
- signal(SIGINT, Raw_TerminateSearch);
- signal(SIGQUIT, Raw_TerminateSearch);
+ signal(SIGUSR1, Raw_TerminateSearch);
if (flag.post)
{
/* CHECKME: does this work?
- * This routine sends a SIGINT (^C interrupt) to gnushogi to awaken it
+ * This routine sends a SIGUSR1 to gnushogi to awaken it
* if it might be busy thinking on our time. This normally isn't needed,
* but is useful on systems where the FIONREAD ioctl doesn't work since
* on those systems the gnushogi feature that lets you interrupt its thinking
{
if (xshogiDebug || localPlayer.appData.debugMode)
{
- fprintf(stderr, "Sending SIGINT to %s\n",
+ fprintf(stderr, "Sending SIGUSR1 to %s\n",
((pid == firstProgramPID) ? "first" : "second"));
}
- (void)kill(pid, SIGINT); /* stop it thinking */
+ (void)kill(pid, SIGUSR1); /* stop it thinking */
}
break;