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
