kfogel@collab.net writes:
> Mark Phippard <markp@softlanding.com> writes:
> > kfogel@newton.ch.collab.net wrote on 03/13/2006 05:04:48 PM:
> >
> > > So I might be +1 on just letting ^C do its thing without interference
> > > from us anymore, in Subversion 1.4. Does anyone else have thoughts on
> > > this? Are DannyB and I missing something important?
> >
> > What are GUI tools like TortoiseSVN and Subclipse supposed to do? We need
> > an effective way to issue a Cancel as well.
>
> Sorry, let me be more sophisticated all over you:
>
> Our libraries would still have cancellation callbacks, and we'd still
> run them; we can even add more such checks.
>
> However, the command line client (one user of the libraries) would
> have a cancellation function that, when invoked, just exits.
I think you mean signal handler above:-) The problem is that
cancelation function is not called often enough. A problem with this
is that our motivation to add more cancelation functions (for use by
other applications) will decrease if we work around the problem in
this way:-)
Seriously, I agree that we should do this. I can't count the number
of times I did C-z, then kill -9 on the cmdline client...
Some ideas that might or might not be worth it/feasable:
* Could we set the flag and then give the library a few seconds to
clean up before exiting (could we use SIGALRM for this?)?
* Would it be possible to implement automatic cleanup by storing the
PID when creating WC locks. Cleanup automatically when there is a
PID in the lock file (for backwards compat) and there is no process
with such a PID.
The goal is to minimize the times the user needs to run cleanup
manually. This is more an improvement than a show-stopper.
Dan: Currently the patch uses exit(), which, according to my reading
of the POSIX spec is not async-singal -safe. So, it seems like we
should use _exit or _Exit instead.
Regards,
//Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Mar 14 09:24:46 2006