[Monotone-devel] nvm.interrupts: beginnings of more robust signal handling

[Zack Weinberg]

I just pushed to net.venge.monotone.interrupts a big hairy patch which
is a work-in-progress implementation of (what I consider to be) saner
handling of Unix signals.  Unfortunately it does a whole bunch of
things at once, because I kept getting shinything syndrome.
Highlights:

* I split up main.cc into Unix and Win32 variants.  I am not a Windows
expert - win32/main.cc probably needs some care and attention from
someone who is.  I'm pretty sure the MSVC #ifdefs are correct, but the
Borland #ifdefs perhaps not so much, and Mingw is totally broken.

* The global sanity and UI objects' constructors no longer do any
work.  This is because global constructors execute outside the
protection of the signal handlers set up in main.cc.  Instead,
monotone.cc::main has wrapper RAII-only objects that do the work.
Similarly, what monotone.cc was doing with an atexit function is now
done with RAII and a call from user_interface::fatal to
sanity::dump_buffer (this last might not be ideal).

* informative_failure is now a proper std::exception.

* The debugging command 'mtn crash' can now crash in many more ways.
The test suite uses this to put a lot more of the crash-handling code
through its paces.

* The giant list of catch clauses is now in monotone.cc::cpp_main
(which wants more refactoring, but this patch is already too big).

* And the big one: "User interrupt" signals (SIGTERM, SIGINT, SIGHUP,
SIGPIPE) no longer kill the process immediately.  They set a flag,
which will be checked for by the Q() function at appropriate points.
I have not put Q() anywhere yet.  This causes a genuine failure
(database_is_closed_on_signal_exit) and a spurious success
(netsync_is_not_interrupted_on_SIGPIPE).  [Incidentally, part of why
'mtn log | less' doesn't give you the prompt back immediately when you
quit the pager, is that SIGPIPE was being ignored for *everything*,
not just netsync.]

I have to figure out where Q() calls should go.  Nathaniel's big
concern with this approach was that we would miss a place and have an
un-^C-able loop - the patch does contain some emergency logic to
address that problem, in that if the signal handler is called twice in
two separate seconds, we give up and die immediately.  Also, ^\
(SIGQUIT) dies immediately, period.  (But, in neither of those cases
will the database be cleaned up.)

So - work in progress, yes, but comments still appreciated.  I'll be
away from the code all day, but will be reading mail and maybe on IRC.

zw