Date: Fri, 31 Aug 2007 18:52:01 -0400 From: Joe Marcus Clarke <marcus@FreeBSD.org> To: freebsd-arch@FreeBSD.org Subject: Understanding interrupted system calls Message-ID: <1188600721.1255.11.camel@shumai.marcuscom.com>
index | next in thread | raw e-mail
[-- Attachment #1 --] 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@FreeBSD.org FreeNode / #freebsd-gnome http://www.FreeBSD.org/gnome [-- Attachment #2 --] -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQBG2JuLb2iPiv4Uz4cRAuAMAJ90Mx4EM5avJpf8l39v3lD6qLGGEgCgkVas F7UWS+dPX84jJeec94h2hFU= =TFHe -----END PGP SIGNATURE-----home | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1188600721.1255.11.camel>