Question

I have a console-mode program that uses SQLite3 to maintain a database file. It takes a while to execute, but it should be safe at any point to cancel, assuming that the database writes happen. (This is all under Windows)

Is it any safer, from the point of a running program, to hit CtrlC in the console than to have another program call TerminateProcess on it?

I’ve noticed that I can get database corruption if TerminateProcess is called- I assume that this is because the program does not get a chance to finish writes. My guess is that CtrlC is better, because the program gets a signal and terminates itself, rather than the OS killing it.

Note that the program doesn’t actually handle the signal (unless SQLite does); I’m talking about the built-in default mechanisms of Win32 executables to handle the CtrlC signal.

To clarify/simplify the question- given that this write has just executed:

fwrite(buf, 1024*1024, 1, stream);

During this write, will TerminateProcess behave differently from CtrlC?

Answer 1

All of these are compelling arguments, but the only way to know for sure is to try it. So I wrote a simple program that allocates a 1GB buffer, assigns some data to it, then writes it to a file using a single fwrite(). I tried several methods to get the write to “corrupt” the data (I was expecting a truncated file, specifically):

• Calling TerminateProcess (via perl’s kill function and Win32::Process::Kill)
• Hitting CtrlC
• Using Task Manager’s “End Process”
• Using Process Explorer’s “Kill Process”

Nothing would stop the write- in every case, the file was the correct size and had the correct data. And although the “Kill” would happen instantly, the process would linger until the write had completed.

It seems conclusive that there is no difference between TerminateProcess and CtrlC from an I/O point of view- once the write starts, it seems guaranteed to complete (barring power outages).