Malcolm Rowe wrote:
> On Wed, Mar 07, 2007 at 01:43:46PM -0500, David Glasser wrote:
>> thing I noticed was that it seems to not want to be canceled; it seems
>> to ignore SIGINTS, and I had to kill -9 it to cancel it. I assume
>
> This is a fairly common user report, incidentally. While we're better
> about cancellation than we used to be, I'm curious as to why we don't
> just make two Ctrl-C's in a row kill the process.
>
> i.e. change the signal handler for our command-line tools from e.g.
>
> static void
> signal_handler(int signum)
> {
> apr_signal(signum, SIG_IGN);
> cancelled = TRUE;
> }
>
> to
>
> static void
> signal_handler(int signum)
> {
> if (!cancelled)
> apr_signal(signum, SIG_IGN);
> cancelled = TRUE;
> }
>
>
> Any reason this isn't a sensible idea? It seems really simple.
-1.
My concern is that people, impatient and trigger-fingered as they are, in
concert with the fact that our cancellation isn't an immediate event but
instead just a scheduled stop-at-the-next-safe-stopping-point, would be
killing their processes all the time.
Maybe I'd be not so opposed if the handler printed a message saying what was
going on and intentionally ignored second-time cancellations that occurred
within some period of time of the first.
$ svn checkout ...
^C
svn: Subversion operation will be canceled at the next safe opportunity.
svn: Cancel again after 5 seconds to terminate the process unceremoniously.
^C
Killed.
$
--
C. Michael Pilato <cmpilato@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Received on Wed Mar 7 20:36:48 2007