Understanding interrupted system calls

In my attempts to debug the problems with ConsoleKit and the
VT_WAITACTIVE ioctl, I delved into the tsleep/msleep code, and I think I
have a pretty good idea when it returns EINTR vs. ERESTART. However,
I'm curious as to why I have to do something like the following to allow
a process waiting in tsleep() to die when it receives a termination
signal (e.g. SIGTERM or SIGINT):

struct sigaction sa;

sa.sa_handler = SIG_DFL;
...
sigaction (SIGTERM, &sa, NULL);

Shouldn't the ps_sigintr set be initialized to the default set of
termination signals by default (e.g. in init_main.c proc0_init())? That
is, shouldn't the list of signals whose default action is to terminate
the process (according to signal(3)) be allowed to interrupt a system
call by default? If one then wants to restart the syscall, they can
explicitly do:

struct sigaction sa;

sa.sa_flags = SA_RESTART;
...
sigaction (SIGTERM, &sa, NULL);

I'm just trying to get a better handle on why terminating a program that
is running the VT_WAITACTIVE ioctl leaves an unkillable process on
FreeBSD, but apparently just causes the program to terminate on Linux.

Joe

--
Joe Marcus Clarke
FreeBSD GNOME Team :: gnome@xxxxxxxxxxx
FreeNode / #freebsd-gnome
http://www.FreeBSD.org/gnome

Attachment: signature.asc
Description: This is a digitally signed message part