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

[Nathaniel Smith]

On Sat, Jul 22, 2006 at 02:25:23PM -0700, Zack Weinberg wrote:
> 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 think they, like most of that code, were just lifted wholesale from
Boost's "execution monitor" library (in its test library).

> 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.

Beats me.  If none of the win32 experts around here object and it
makes the buildbot happy, *shrug*.

> >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.

Sure.  To make sure it gets ignored in netsync, I guess we can just
start up a server and send SIGPIPEs at it, and see if it dies.

For it not getting ignore otherwise, I'm not sure -- on POSIX we can
do:
  $ mkfifo blah
  $ mtn log > blah &
and then send a SIGPIPE at it and make sure it dies.  Dunno what to do
on win32, though.  (Does win32 even have SIGPIPE?)

> >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?

Sure.

-- Nathaniel

-- 
"On arrival in my ward I was immediately served with lunch. `This is
what you ordered yesterday.' I pointed out that I had just arrived,
only to be told: `This is what your bed ordered.'"
  -- Letter to the Editor, The Times, September 2000