Date: Tue, 1 Oct 2002 16:38:40 +0100 From: Tony Finch <dot@dotat.at> To: Robert Watson <rwatson@FreeBSD.org> Cc: John Baldwin <jhb@FreeBSD.org>, cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/kern kern_synch.c Message-ID: <20021001163840.A28904@chiark.greenend.org.uk> In-Reply-To: <Pine.NEB.3.96L.1021001111753.32141A-100000@fledge.watson.org>; from rwatson@FreeBSD.org on Tue, Oct 01, 2002 at 11:24:07AM -0400 References: <200210011410.g91EA9EZ026286@freefall.freebsd.org> <Pine.NEB.3.96L.1021001111753.32141A-100000@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Oct 01, 2002 at 11:24:07AM -0400, Robert Watson wrote: > > Yeah, the notion of signals and threads is still a bit cloudy in my mind. > Some signals are clearly at the scope of the process: SIGKILL, SIGXCPU, > etc, apply to process-wide conditions, often managed using POSIX process > conventions (PIDs, etc). Other signals are generated in response to > execution flow issues -- SIGSEGV is just one example of that, and are > generated by a KSE, but presumably intended for a thread at the user > level. I'm not sure that that's the right attitude, since a SEGV is usually a sign that the program has gone insane and needs to be put down -- just killing one thread is liable to lead to more SEGVs later. The other possibility is that the programmer is insane and should be put down (Steven Bourne's shell's memory allocation; my bytecode interpreter's user-defined function handler...) which perhaps does want per-thread handling even if it should be discouraged. Tony. -- f.a.n.finch <dot@dotat.at> http://dotat.at/ SOUTHEAST ICELAND: EAST OR SOUTHEAST 4 OR 5, INCREASING 6 OR 7. RAIN AT TIMES. MODERATE OR GOOD, OCCASIONALLY POOR. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20021001163840.A28904>