Quote:
Originally Posted by
hakermania
So you claim that if I make a sync-safe function using the above sync-safe functions, then the handler will be executed?
Not necessarily, depending on how the program is killed. There are signals that cannot be interrupted. Further experimentation is required.
What I would do is create and close file when the program
starts. When the signal handler is called, unlink() it. If the program cleans up properly, the file will disappear, if not, it will remain.
Quote:
And if this is true then how does the system determine:
a) Where in the memory the handler sits for each application
b) If the handler is sync-safe or sync-unsafe
It doesn't "determine" unsafe things. It doesn't "punish" unsafe code. It's the software interrupt itself that is unsafe, really...
It halts your main program, whatever it's doing, finished or not; then does a graceless jump to a temporary, limited stack space. It leaves whatever was happening, dangling. main could be
inside printf or malloc already when you try and call them in your interrupt handler. That would be bad.
So to get around this, you have to talk directly to the kernel with system calls, instead of using your handy stdio libraries and such. This avoids tearing out your floor from under you by accident.
Quote:
What different does the system do instead of sending SIGTERM, waiting for the process to exit, and, after timing out, sending SIGKILL? Because it does something different, it not only sends SIGTERM, because if I send it, it just works.
I'd wonder if your disks are still mounted read-write by the time your program is killed. If they're not, you'll never see any changes even if your interrupt handler works.
