E.g. in a GHC repo:
$ darcs pull
[type control-C soon but not immediately]
[wait a while - around 15 seconds in my case]
withSignalsHandled: Interrupted!
$

After typing ^C the system appears to have high network (not CPU) usage
for some time before quitting.

Waiting a long time, unresponsively, before quitting when requested, is
not nice behavior for a unix process :)

(also "withSignalsHandled: Interrupted!" seems odd to say;
"withSignalsHandled" is part of the implementation. "Interrupted by
signal X" or some such might be better?)

Isaac

Thanks, Isaac.

Marking this as a bug, though probably not one that I would know how to fix. 
Note that this also occurs during optimize --reorder, where it would at least be
nice to get the 'Can't handle interrupt because darcs is doing a sensitive
operation'.

On the other hand, do note Isaac's comment about 'withSignalsHandled'.  It
should be fairly easy to replace that with something more user friendly.

I'm having similar problems with darcs push.  But it's hanging for several hours
trying to get to the GHC repo, so I press ctrl-C repeatedly, trying to stop it.
Eventually it says "darcs: too many pending signals" and quits without even
removing _darcs/lock.

If darcs handled signals promptly when it wasn't in the midst of sensitive
calculations, it wouldn't even need to quit for "too many pending signals" either.

But what about during optimize --reorder? If darcs has no choice but to exit
fast, is it possible to do it cleanly? At least, if the next time darcs starts
it recognizes that the repository is in the midst of an optimize --reorder, is
it possible to bring the repository to a consistent state from there?  If so,
then I believe it's a somewhat interruptible operation (although it would be
acceptable if the intermediate work were lost); otherwise I think it's a darcs
problem, not to be crash-safe.  I know I can manually make particular operations
crash-safe by making a backup copy in case something goes wrong; so maybe it
would be worth it for darcs to do something similar.  But can't darcs do all its
computation first, so any shuffling around of files needed, in which the
repository is temporarily inconsistent, doesn't take a particularly large amount
of time?

isaacd: I suspect that the trouble with interrupting a darcs push is related to
an noninterruptable ssh operation.  Fixing this is probably quite tricky,
although it might be easy for the right person (which is not me).  Generally,
interactions with external programs are tricky, and I know of no easy/safe way
to interrupt them.

The issue with darcs optimize is different.  The real fix is to switch to a
repository format that is friendly to atomic changes, and that's what we're
working on.  The hashed-inventory format helps part of the way, and the
(planned) hashed-pristine format should finish this off.  Once we have a
naturally atomically-updateable repository format, the only challenging bit will
be updating the working copy, and that's something much less of an issue
(particularly with optimize!).

David

David,

Would you agree that this is resolved about as much as it can be right now? The
hashed formats you mentioned have been implemented, and I'm sure that's much
that can be done about interrupting external operations. 

   Mark

On Sat, Feb 09, 2008 at 07:20:40PM -0000, Mark Stosberg wrote:
> Would you agree that this is resolved about as much as it can be right now? The
> hashed formats you mentioned have been implemented, and I'm sure that's much
> that can be done about interrupting external operations. 

Yeah, may as well resolve this.  There are still a few potentially slow
operations, but interrupting a file-download is a risky business.  And it's
*far* better in the hashed repository than it was previously.
-- 
David Roundy
Department of Physics
Oregon State University

okay, in that case I guess I will just continue to type ctrl-C a dozen or so
times to terminate darcs pull/push operation.  This leaves the SSH operation
running and it will print a time-out message to the same terminal rather later,
but that doesn't seem to be a problem for me.  Is this the best user-interface
we can come up with, given current limitations?

On Sat, Feb 09, 2008 at 09:16:31PM -0000, Isaac Dupree wrote:
> okay, in that case I guess I will just continue to type ctrl-C a dozen or so
> times to terminate darcs pull/push operation.  This leaves the SSH operation
> running and it will print a time-out message to the same terminal rather later,
> but that doesn't seem to be a problem for me.  Is this the best user-interface
> we can come up with, given current limitations?

Ah, so this is when running with ssh that you have trouble? In that case,
the problem is most likely that darcs never receives the sigint, since it
goes to the ssh/scp which fails (at least, I think that's what's
happening).  I'm not sure how to deal with this.  It's also possible that
when dealing with scp's we are catching and ignoring sigints, treating them
as if they were a generic ssh-related error (e.g. file on remote repository
doesn't exist).  What you describe is definitely a bug.  Are you running
with a darcs 2 prerelease? If so, could you try running with --debug and
see if you get output after hitting ctrl-C?
-- 
David Roundy
Department of Physics
Oregon State University

no, sorry, it's just the situation described before, pull via HTTP or push via
SSH are what I did, which make darcs say that thing about too many interrupts
after I press ctrl-C several times. (at which point I get a shell prompt again.)
 I haven't tried darcs2 and probably don't have time to, now.

I just tried interrupting an HTTP pull with the darcs 2 pre-release, and darcs
returned immediately. The error return wasn't ideal, but I consider it good enough:

###

darcs: failed to read patch:
Wed Jul 12 15:18:09 EST 2000  jesse
  tagged v1-1
user error (failed to fetch:
http://mark.stosberg.com/darcs_hive/cgi-app/_darcs/patches/20000712201809-a5c95-2e8b213b949d7fcb26a0924cb461501ea31e6968.gz
ExitFailure 2)

####

The ideal error message wouldn't mention something like "darcs caught interrupt
signal. Exiting."

###

After I canceled the repo was left in a consistent state. Namely, no changes
were recorded. 

###

I'm marking as a resolved-in-unstable based on this experience and David's
feedback. 

Isaac: Please do re-open this ticket if you test with a Darcs-2 pre-release and
find that that the issue persists.