Debugger and process monitor suggestion

Blair,

In addition to my bug report re #terminateOnClose, I am reminded of
something that I have wanted for a while: the ability to use the process
monitor to attach to a Process, debug it, and exit the debugger w/o
terminating the process or signalling any semaphore/delay on which it is
waiting.

I find it quite advisable to terminate on close as a default behavior.
In fact, I had Dolphin lock up this morning and Windows shutdown on
killing it as an indirect result of the #terminateOnClose bug.  The
reality is that a device driver got in a snit, but it happened because
of activity following an error that its associated COMponents raised.

I guess the bottom line is that it would be nice to have
instance-specific #terminateOnClose and to get the Process Monitor
(perhaps optionally??) to set it to false.  However, it would (in
general) be of use to me only if the debugger can leave semaphores
unsignalled, return them to the waiting list, etc..  Better you than me :)

Have a good one,

Bill


--
Wilhelm K. Schwab, Ph.D.
[hidden email]

"Bill Schwab" <[hidden email]> wrote in message
news:[hidden email]...
I've removed the whole #terminateOnClose thing for the next beta. You have
the choice of being prompted, but if you suppress the prompt then the
process will always be terminated in future - it's not safe (as you rightly
point out) to do anything else. Actually I think that particular bug was
behind a lot of the odd walkbacks I'd been seeing recently that seem to have
been caused by more than one UI process pumping messages. I wouldn't be at
all surprised if others had been affected by this too.

If you need to allow the process to continue to run, then you can just use
the Go/Detach command on the Debug menu, just as you could in D5.

Regards

Blair

Blair,

> If you need to allow the process to continue to run, then you can just use
> the Go/Detach command on the Debug menu, just as you could in D5.

...if I had known about it :)  I just did a quick test with a thread
that waits on a semaphore that is never signalled, and it appears that
with go/detach, the debugger indeed leaves it still waiting on the
semaphore, which is exactly what I want for some types of threads.  It
should be a big help in the near future.  THANKS!!!!!

A small suggestion would be to look at a property of the debugged
Process (#preferDebuggerDetach???) that when set to true causes the
debugger to favor go/detach over terminate, at least under some
circumstances.  As to whether that would be only via debug in the
process monitor or under all cirumstances except a walkback (not sure
how to treat #halt), I'm not sure I'd have a preference, as long as its
safe most of the time, and always safe when the feature is inactive.

One could always use the process monitor, a workspace, or just an
explicit command to the debugger to terminate such a process.  Usually
when crawling around in the relevant code, I am working against a
timeout, so any kind of idiot proofing I can get is helpful.

Have a good one,

Bill


--
Wilhelm K. Schwab, Ph.D.
[hidden email]