Date: Tue, 1 Oct 2002 11:45:04 -0400 (EDT) From: Robert Watson <rwatson@FreeBSD.org> To: Tony Finch <dot@dotat.at> 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: <Pine.NEB.3.96L.1021001113928.32141C-100000@fledge.watson.org> In-Reply-To: <20021001163840.A28904@chiark.greenend.org.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 1 Oct 2002, Tony Finch wrote:
> 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.
Yeah -- the examples I had in mind were things like:
(1) Floating point exception due to un-handled floating point case which
the process wants to be able to recover from.
(2) Local virtual memory/distributed shared memory implementation that
relies on catching SIGSEGV to detect page-not-present faults in the
thread, and wants to be able to restart the thread after processing
the request.
(3) Interpretation of SIGILL and related signals for local exception and
system call handling. I've worked with a couple of OS emulators that
rely on catching SIGILL to handle "system calls".
If these cases are sufficiently evil, I'm willing to go with the flow
whatever the concensus may be, but definitely do want to support the
notion that signals are generally targetted at processes, not threads,
unlike some other thread implementations.
Robert N M Watson FreeBSD Core Team, TrustedBSD Projects
robert@fledge.watson.org Network Associates Laboratories
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?Pine.NEB.3.96L.1021001113928.32141C-100000>