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

[Zack Weinberg]

On 7/21/06, Nathaniel Smith <address@hidden> wrote:
> Hmm, I don't think anyone has ever compiled monotone using Borland
> anyway, but Mingw has always been our supported win32 build platform.

Well, someone went to the trouble of writing a bunch of #ifdef
_BORLANDC blocks in the old main.cc, but if no one does it, that might
explain why they looked totally broken. :-)

I looked at MSDN a bit more this morning and came to the conclusion
that we can do what we are trying to do in a compiler-independent way
by using SetUnhandledExceptionFilter, so I coded that instead.
Completely untested of course, but at least it doesn't #error on Mingw
anymore.

[... stuff you like skipped ...]
> > * The giant list of catch clauses is now in monotone.cc::cpp_main
> > (which wants more refactoring, but this patch is already too big).
>
> Hmm, I kind of like how the current design keeps all the crazy
> signal/exception/etc. handling (that never changes) out in one file,
> and then all the actual monotone-related logic is in a different file.

Understood, but I think duplicating it all between unix/main.cc and
win32/main.cc is worse, and I think the problem you're seeing is
better addressed with some more judicious refactoring of cpp_main,
which was a mess before these changes and is still a mess today.

> Oops, that SIGPIPE thing is a bug that I think we've regressed on a
> few times; need to fix it and figure out how to properly test for it.

The fix is just to handle SIGPIPE like SIGINT from unix/main.cc and
then have netsync.cc override that, but I don't know how to test it
properly myself.

> To refine that slightly, my concern isn't so much that we'd have an
> un-^C-able loop -- that'd just be a simple bug, trivially fixed.  My
> concern is more that we might have an indefinite number of those,
> being added over an indefinite period of time, and no way to detect
> when that had happened.  (In the general case, detecting such bugs is
> not computable; in practice, it's probably solvable in lots of real
> cases and the real-time folks probably know methods, but we have no
> tools to actually do such checking, so that doesn't help.)
[...]

Upon thinking about it a bit more, I don't have a good answer to these
concerns, and I'm also not eager to be hunting through the code for
the right places to sprinkle Q().  Further, after experimenting and
discussion on IRC, it now seems that leaving -journal files around is
not nearly as much of a problem as I thought.  So I've re-done
.interrupts so that the response to 'user interrupt' signals is just
to quit, as you suggested, and why don't we see how bad that is over
the course of the coming development cycle, and rethink if it proves
to be an issue?

zw