Not always. The kill system call can be used to send any signal, it's just got a name that implies you're sending something like SIGKILL or SIGTERM. I have written C programs that use kill for harmless inter-process communication.

SIGUSER is quite common for that. Or SIGHUP.

By convention, SIGHUP is used by daemons to signal a change of configuration.

Not necessarily. You can send the CONTinue signal to a process using the kill command. This will not cause the process to terminate.

Or use "kill -0 <pid>" to check if a signal can be sent/the pid exists.

Or use kill -USR1 <pid> to check the progress of dd

Only if you've enabled it. If you've not, the process will terminate unceremoniously (in a mechanism borne entirely out of hatred for users.)

This is my favourite part of dd: The "will I receive a status report or will I terminate my long-running copy?" gamble.

Is that a BSD thing? I've never had to enable it on Linux to avoid killing the process.

Me neither, on debian.

It's SIGINFO on the BSD's, and works with just about any process (though obviously not everything has a customized handler). Also handily mapped to Ctrl-T.

No because only SIGQUIT, SIGABRT, SIGKILL, SIGTERM and often SIGHUP are supposed to do that. All of the other signals have wildly varying meanings. See man 7 signal: http://unixhelp.ed.ac.uk/CGI/man-cgi?signal+7

You can also cancel (sigint, eg ctrl c) processes via kill.

Or use sigchld to a parent to get rid of zombie children.

SIGHUP is also used to tell some certain daemons to re-read their configuration files without quitting.