> From: Garrett Rooney [mailto:rooneg@electricjellyfish.net]
>
> Bill Tutt wrote:
>
> > Isn't this because we aren't talking to the datastore properly in
the
> > first place? Our database should NEVER get wedged. I thought we'd
talked
> > about how to fix this. We should work on that rather than this
approach.
> > If we're not willing to tackle that work item for 1.0 then I begin
to
> > wonder about what skewed ideas people might have about how
> > stable/reliable a 1.0 relase of Subversion should be.
>
> [snip]
>
> > If you could refresh my aging brain on why the database gets wedged
and
> > why we're not addressing that before doing things this way I'd
greatly
> > appreciate it.
>
> well, right now, it can easily get wedged just because of the fact
that
> there is no attempt to catch a SIGINT, so you hit control-c and your
> process just exits. if you're holding locks inside berkeley db, then
> you don't clean them up, so the repos can get wedged. without some
kind
> of cancelation support, this is unavoidable.
>
Didn't we talk about a way to handle detecting this, and knowing when to
correctly tell BDB to recover itself?
If you can't hit Ctrl-C using the command line program and have
everything still work afterwards, then we have serious issues, and we
should address those. We either have an ACID datastore, or we don't. If
we don't we're severely hampered in designing a robust system. Or,
alternatively, we need to seriously reconsider supporting the ra_local
approach. (or at the very minimum from using ra_local directly in the
same process).
Catching SIGINT isn't going to guarantee anything about random events
not going to cause lock leaks inside of the data store. We need to
ensure that starting a new process that uses the data store can reliably
bootstrap itself into a useful datastore. We MUST have a reliable ACID
data store.
> > If you'd be so kind as to reintegrate the cancellation editor then
my
> > objections about this approach would disappear completely. That way
> > multi-threaded UIs can have what they want, and the command client
can
> > have what it wants.
>
> ok, explain to me how you think the cancelation editor should work?
the
> client api doesn't have any means to pass in an editor anymore, that
was
> replaced with callback functions a little while ago, so it's not like
> the client app can just wrap its own editor around whatever it's
calling.
>
> the way i see it, we still have to get the callback and the baton from
> somewhere, and if we're going to have multiple batons, we have to pass
> it explicitly to each function, otherwise i can't see how we're
supposed
> to get at it safely without locks.
You pass in the callback function pointer and baton into public APIs,
and compose the editor you're using with the cancellation editor. Then
you're done. If we don't do composition internally anymore then we add
the callback to the existing editor batons, and call the cancellation
function before calling more editor methods.
> plus, we only get cancelation during
> editor drives, which philip had some second thoughts about.
>
Yeah, I think this gets into the necessity of how often a SIGINT
checking cancellation operation needs to run vs. a cancellation
heuristic that tries to check for cancellation before possibly expensive
operations. (aka network transmissions, etc...)
But lets dig down on this database wedging a bit more. My brain needs to
page fault in a bit more context yet.
Bill
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Sep 18 22:24:00 2002