Understanding interrupted system calls

[Joe Marcus Clarke]

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 at FreeBSD.org
FreeNode / #freebsd-gnome
http://www.FreeBSD.org/gnome
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: This is a digitally signed message part
Url : http://lists.freebsd.org/pipermail/freebsd-arch/attachments/20070831/62641453/attachment.pgp