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.
> 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. plus, we only get cancelation during
editor drives, which philip had some second thoughts about.
-garrett
---------------------------------------------------------------------
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:07:53 2002