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
>> <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> -- 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 [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to