Re: Changing the way we do cancellation. (was: Re: [PATCH]: Let users cancel out of command line client immediately if they signal 3 times)

[Daniel Berlin <db...@dberlin.org>]

> I still feel like we're just postponing the real solution to this
> problem.  

Which is what?

Rewrite everything so we can cancel at any time and still cleanup safely
very fast? :)

Right now, the feature is *not* designed to be cleanup-safe, nor would
such a thing be fast.  It is *just as unsafe as killing the client*.

Doing something that can support cleanup fast would probably take
rewriting the way our wc works (in terms of locking, etc).

Designing such a thing may be useful for our developers.  I'm really not
arguing that it isn't useful to IDE developers.

I'm simply arguing that it's not the best solution for the command line
client to use such an interface, until it exists, when a simpler method
with the same safety properties, much greater interactivity, and is more
intuitive to users, exists.

IMHO, it would also make your design goals for such a cleanup-safe
cancellation mechanism that much easier and cleaner.

It's a much harder problem to support *both*
1. Something that can satisfy the user, in a single threaded completely
response-time dependent interactive application wants
2. Something that can satisfy the user in a multi-threaded IDE where you
can probably do the cleanups in the background.

If you take away the need to design for #1 in your cancellation
mechanism, I'd argue it will become cleaner and easier to implement.


> There are a great many situations where you cannot simply
> kill off the client when you want to cancel an operation.
>   What
> happens when you embed the client in another program?
> 
Not all of our users have the same needs.  We could choose one of the
signals we currently ignore completely, and specify it to cancel instead
of kill, if that is the route we wanted to take and you are worried
about such a thing.  Though it's not clear what it buys you over
killing, since you have the same safety properties.

> -garrett
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: Changing the way we do cancellation. (was: Re: [PATCH]: Let users cancel out of command line client immediately if they signal 3 times)

[Vincent Lefevre <vi...@vinc17.org>]

On 2006-03-13 21:34:21 -0500, Daniel Berlin wrote:
> Not all of our users have the same needs.  We could choose one of the
> signals we currently ignore completely, and specify it to cancel instead
> of kill, if that is the route we wanted to take and you are worried
> about such a thing.

Isn't that the difference between SIGINT (usually Ctrl-C) and SIGQUIT
(usually Ctrl-\)? IMHO, the SIGQUIT handler should quit immediately,
with minimal clean-up, and the SIGINT handler should do a full clean-up
after displaying a message (and I agree that a second SIGINT should
abort the clean-up immediately).

-- 
Vincent Lefèvre <vi...@vinc17.org> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / SPACES project at LORIA

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: Changing the way we do cancellation.

[Greg Hudson <gh...@MIT.EDU>]

On Tue, 2006-03-14 at 12:40 +0000, Julian Foad wrote:
> There's an idea worth investigating: can we make a portable locking API whose 
> implementation uses the system's locking facilites (fcntl, etc.) where 
> available and plain files otherwise?

Such an API would create the risk that Subversion on one platform would
be using plain file locking, and on another platform would be using
POSIX-type file locking, on the same working copy in a networked file
store.

If we were planning for 1.0 now, I think it would be reasonable to just
use apr_file_lock().  We do that for FSFS (for commits, and pre-1.3 for
all operations) and it still works okay in most network filesystem
setups.  But I'm not sure it's reasonable to make svn working copies
stop working in the few exceptional cases during the 1.x line.


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: Changing the way we do cancellation.

[Julian Foad <ju...@btopenworld.com>]

Daniel Berlin wrote:
> 
> Right now, the feature is *not* designed to be cleanup-safe, nor would
> such a thing be fast.  It is *just as unsafe as killing the client*.

No, it's not just as unsafe as killing the client.  "svn commit" leaves locks, 
as you pointed out, but the cancellation mechanism avoids leaving locks from 
other commands e.g. "svn update" and is valuable because of it.


> I'm simply arguing that it's not the best solution for the command line
> client to use such an interface, until it exists, when a simpler method
> with the same safety properties, much greater interactivity, and is more
> intuitive to users, exists.

I agree that the ability to quit (reasonably quickly) is important, and that 
the command-line app should use a simple exit if the cancellation mechanism 
doesn't exit quickly enough.

Some users will want "svn" to do as much clean-up as it can, and would consider 
it fair to have to wait a while (comparable with the time the command has taken 
up to that point), but if this is going to take more than a second or so there 
should be some indication that "svn" has received the interrupt and is cleaning up.

I support the concept that your (Daniel's) patch embodies: the first interrupt 
makes Subversion try to exit nicely, and a subsequent one forces an immediate exit.

As for the details of operation, there are many possible variations (of number 
of interrupts required, at which stages messages are printed, and potentially 
minimum and maximum times between stages).  I'd like the scheme to be aas 
simple as possible except that the user should be informed of the progress of 
the cancellation attempt so that he/she can make an informed choice of whether 
to force a hard exit.  So I suggest:

   * The first interrupt is noted as usual.

   * When the normal code path later checks and notices the request, it prints 
a message indicating that the operation is aborted and it is cleaning up.  This 
provides confirmation that the cancellation request is taking effect, and 
enables the user to better judge whether to wait for Subversion to finish what 
it is doing.

   * A second interrupt (whether before or after the app notices the request) 
causes an immediate exit.

If the user hits Ctrl-C and doesn't see the "Aborted; cleaning up..." message 
within what she considers to be a reasonable time, or does see it but the app 
still doesn't finish within a reasonable time after that, she can choose to 
press Ctrl-C again and the process will quit immediately.


> IMHO, it would also make your design goals for such a cleanup-safe
> cancellation mechanism that much easier and cleaner.
[...]

Yup, that's nice.


Greg Hudson wrote:
>> Why can't we clean up those locks [left by an interrupted commit]?

Daniel Berlin wrote:
> We handle it like any other error that occurs during commit/whatever.
> Anything else would require restructuring the wc code in very
> significant ways, AFAIK.

Maybe, but it would be good if somebody would investigate, in case it turns out 
not to be so hard.

> Also, doing such cleaning up would itself takes a long time on a gcc
> working copy, since it has a ton of directories. I imagine if we used
> fcntl locking instead of lock files, we could just go away and the
> kernel/libc would clean up after us.

There's an idea worth investigating: can we make a portable locking API whose 
implementation uses the system's locking facilites (fcntl, etc.) where 
available and plain files otherwise?

- Julian

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org