> 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.
> And trying to clean up after a seg faulr simply doesn't work in general.
You'd think so, wouldn't you? However, it turns out to actually be quite
possible in real life; especially if all you want to do is to release some
resources (like database locks) and then exit in peace. (Note that I've
been back and forth on this issue two full circles in previous history.)
Yes, I understand that a user level program cannot make the same GUARANTEE
of correctness that a properly debugged kernel can for file descriptors,
but in reality, a segfault will be caused by some stupid bug dereferencing
NULL, or double-freeing memory, or some-souch; neither of which is likely
to thrash the data structures you have pre-allocated to be able to clean
up and go home. And as you don't re-install the SEGV handler (now THAT
would be pushing it!) in the 1-out-of-1000-th case that you can't clean up
then, well, you're no worse off than before.
I haven't yet seen an argument that convinces me a signal handler is not
the way to go. However, error codes will probably work as well for the
Ctrl-C case, and as y'all are already writing code and I'm not prepared to
spend the time to Do It My Way, then I should just shut up, shouldn't I? :-)
Cheers,
/ h+
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Sep 13 04:59:27 2002