On Thu, Sep 12, 2002 at 07:57:17PM -0700, Jon Watte wrote:
>
> > There's also the small problem that longjmp'ing out of a signal handler
> > loses context, which means that we can't clean up the database locks
> > anyway -- defeating the purpose of this exercice.
>
> Note that my proposal was that anyone who enters context, also registers
> a cleanup handler & magic token for this context. When you're done with
> your protected area, you un-register the context. This is somewhat
> analogous to creating a memory pool and passing it "downstream" and then
> de-allocating the entire pool when you're done, which I believe subversion
> makes good use of by getting it from APR.
Unfortunately, it might not be safe to call the DB api to release locks
if you've longjmped out of a DB call in the first place, because the DB
might not play by this "register your cleanup routines" rule internally.
(Just like third party libs might call malloc() rather than apr_palloc()).
Take this hypothetical scenario:
open() {
mutex_enter();
obtain_lock();
mutex_exit();
}
transaction() {
mutex_enter();
do_long_blocking_thing();
mutex_exit();
}
close() {
mutex_enter();
release_lock();
mutex_exit();
}
Now, let's say we longjmp out of do_long_blocking_thing up to something
that calls close() to release the lock.
Note the the longjmp prevents transaction()'s mutex_exit() from being
called. This means that when the cleanup routine calls close(), the
mutex_enter() will block. Badness.
Now, you'll argue that "mutex_exit()" should be added to the cleanup-list
in each of these functions. That's true, but these functions are part
of the database implementation, not part of Subversion. We might even be
able to patch BDB but we can't patch Oracle.
--ben
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Sep 13 15:00:18 2002