Date: Thu, 10 May 2001 10:05:29 -0700 (PDT) From: John Baldwin <jhb@FreeBSD.org> To: Robert Watson <rwatson@FreeBSD.org> Cc: freebsd-current@FreeBSD.org, Garrett Wollman <wollman@khavrinen.lcs.mit.edu> Subject: Re: pgm to kill 4.3 via vm Message-ID: <XFMail.010510100529.jhb@FreeBSD.org> In-Reply-To: <Pine.NEB.3.96L.1010510123858.4086A-100000@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 10-May-01 Robert Watson wrote: > > On Wed, 9 May 2001, Garrett Wollman wrote: > >> <<On Tue, 8 May 2001 23:31:51 -0400 (EDT), Robert Watson >> <rwatson@FreeBSD.ORG> said: >> >> > I followed everything here fine until you asserted that the debugger >> > shouldn't need any locks. >> >> When the debugger is running, everything else should have been >> forcibly halted. > > The process and signal-related structures may be inconsistent if the > debugger disregards existing locks held over those structures. It does > not matter if code is currently still executing, it matters that > preemption can occur. The choices appear to be: > > 1) Disregard locks and risk corruption If I'm sending a kill -9 to a program, I could really care less about clobbering the SIGABRT it is currently getting sent. :) I think that a kernel debugger is a case of where one allows much foot shooting to occur. > 2) Fail if a lock is held mtx_trylock() makes this relatively easy to implement in many cases. -- John Baldwin <jhb@FreeBSD.org> -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?XFMail.010510100529.jhb>