I was thinking more along the lines of using mfaktc's internal data for the purpose of determining whether an exponent was finished and its result ready to send. Results.spl is a reasonable name for it.
I also didn't see any signal handler in mfaktc when I was reading the source last night. I take it that means that when I press ctrl-c, we are depending on the OS to shut the program down and close any open checkpoint file? (This doesn't make me feel very safe).

[QUOTE=Christenson;261687]I was thinking more along the lines of using mfaktc's internal data for the purpose of determining whether an exponent was finished and its result ready to send. Results.spl is a reasonable name for it.
I also didn't see any signal handler in mfaktc when I was reading the source last night. I take it that means that when I press ctrl-c, we are depending on the OS to shut the program down and close any open checkpoint file? (This doesn't make me feel very safe).[/QUOTE]

worktodo.txt, results.txt, mfaktc.ini and checkpoint files are opened right before and closed after being accessed. So the chance for this is quiet low because most of the time there is non of the files above opened.

Oliver

[QUOTE=TheJudger;261689]worktodo.txt, results.txt, mfaktc.ini and checkpoint files are opened right before and closed after being accessed. So the chance for this is quiet low because most of the time there is non of the files above opened.

Oliver[/QUOTE]
This is perfectly good practice, but when I have 30 or 40 hours work involved, I don't like nonzero chances where I don't have to take them!

A signal catcher (for ^C) would simply set a variable so that a new class would not be started, and return to the main program to allow it to close files and exit properly.

E

Got to thinking about this further, as my Xubuntu PC crashed the other night. We want to do multiples of the checkpoint files, like P95 does, because the other way to lose a bunch of work is to have the computer as a whole crash, whether due to power loss or O/S misbehavior.

Found out the Robotics team was given a GEFORCE GT480 card, but we didn't get to checking power supplies and probably need a second monitor for it....that'll really do some damage!

Hi,

[QUOTE=Christenson;261735]This is perfectly good practice, but when I have 30 or 40 hours work involved, I don't like nonzero chances where I don't have to take them!

A signal catcher (for ^C) would simply set a variable so that a new class would not be started, and return to the main program to allow it to close files and exit properly.

E[/QUOTE]
what about[LIST][*]first time ^C received: stop after the current class has finished and checkpoint file is written[*]second time ^C received: stop immediately without taking care of closing files, etc.[/LIST]
Should be really easy to implement. :smile:

Oliver

P.S. hopefully this is not OS dependent, I never did signal handling on Windows...

[QUOTE=TheJudger;262012]hopefully this is not OS dependent, I never did signal handling on Windows...[/QUOTE]I'm not sure if Windows treats it differently if you hit Ctrl-C on the keyboard vs clicking the [X] to close the window?

In either case, on receiving the first break command, something should immediately appear onscreen to the effect of "break command received, stopping after next class (hit Ctrl-C again to exit immediately)".

I know some CL applications which cant be closed by Ctrl+C - instead, they print ♥ and continue working:smile:

I intend to be lazy about this and copy whatever method P95 is using, which is that he catches a signal and sets a variable telling things they need to exit.

I think that it is an awful idea not to be able to tell a program, any program to stop. The inability to stop a program in an operating system indicates a problem with the operating system.

I like Oliver's suggestion, except that I think all files should get closed on that second ^C. (Remember that it is going to be reasonably hard to hit ^C in the middle of writing a file anyway). If we really need an asynchronous, middle-of-writing-files kill, that is what the OS is for.

[QUOTE=Christenson;262038]I think that it is an awful idea not to be able to tell a program, any program to stop. The inability to stop a program in an operating system indicates a problem with the operating system.[/QUOTE]On all Unix-like systems I know of, sending the KILL signal is instant death for the process receiving it. That's not quite the same as removing the process from the process table because zombie processes are not removed by a KILL signal; however they are already dead for all practical purposes.

Don't know about the situation under other operating systems.

Paul

Win32 has a limited range of signals you can install a handler for; even then, the handler runs [i]once[/i] only. Hitting Ctrl-C will run your SIGINT handler; hitting it again will kill your program, without running the handler.

[QUOTE=xilman;262060]On all Unix-like systems I know of, sending the KILL signal is instant death for the process receiving it. That's not quite the same as removing the process from the process table because zombie processes are not removed by a KILL signal; however they are already dead for all practical purposes.[/QUOTE]

Any *nix which follows the POSIX.1 standard (all modern *nix) have two signals which cannot be "caught" or "ignored": SIGKILL and SIGSTOP. SIGKILL stops execution and releases all resources(*) including closing any open files. SIGSTOP simply stops execution without releasing resources; it can be restarted in the future.

(*) - As xilman said above, a "zombie" processes can be created by a SIGKILL, but only if it was a "forked" process and its parent process is still running and hasn't acknowledged the SIGCHILD signal generated indicating its death. In this case the only resource still consumed is the Process structure entry -- a few kbytes at most.

(Trivia: since there are a finite number of Process structures allowed in a system at any one time (often 65535), this can be used as a denial of service attack known as a "Wabbit".)