mfaktc: a CUDA program for Mersenne prefactoring - Page 85

Christenson · 2011-05-18, 13:23

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).

TheJudger · 2011-05-18, 14:06

Quote:

Originally Posted by Christenson

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).

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

Christenson · 2011-05-18, 21:54

Quote:

Originally Posted by TheJudger

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

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

Christenson · 2011-05-20, 01:43

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!

TheJudger · 2011-05-22, 19:35

Hi,

Quote:

Originally Posted by Christenson

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

what about

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.

Should be really easy to implement.

Oliver

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

James Heinrich · 2011-05-22, 19:45

Quote:

Originally Posted by TheJudger

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

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)".

Karl M Johnson · 2011-05-22, 19:54

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

Christenson · 2011-05-23, 01:54

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.

xilman · 2011-05-23, 08:06

Quote:

Originally Posted by Christenson

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.

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

jasonp · 2011-05-23, 10:54

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

chalsall · 2011-05-23, 13:37

Quote:

Originally Posted by xilman

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.

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".)

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
mfakto: an OpenCL program for Mersenne prefactoring	Bdot	GPU Computing	1676	2021-06-30 21:23
The P-1 factoring CUDA program	firejuggler	GPU Computing	753	2020-12-12 18:07
gr-mfaktc: a CUDA program for generalized repunits prefactoring	MrRepunit	GPU Computing	32	2020-11-11 19:56
mfaktc 0.21 - CUDA runtime wrong	keisentraut	Software	2	2020-08-18 07:03
World's second-dumbest CUDA program	fivemack	Programming	112	2015-02-12 22:51

2011-05-18, 13:23	#925
Christenson Dec 2010 Monticello 3403₈ Posts	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).

2011-05-20, 01:43	#928
Christenson Dec 2010 Monticello 1795₁₀ Posts	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!

2011-05-22, 19:54	#931
Karl M Johnson Mar 2010 3·137 Posts	I know some CL applications which cant be closed by Ctrl+C - instead, they print ♥ and continue working

2011-05-23, 01:54	#932
Christenson Dec 2010 Monticello 5×359 Posts	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.

2011-05-23, 10:54	#934
jasonp Tribal Bullet Oct 2004 3×1,181 Posts	Win32 has a limited range of signals you can install a handler for; even then, the handler runs once only. Hitting Ctrl-C will run your SIGINT handler; hitting it again will kill your program, without running the handler.