Treating POSIX signals as exceptions?
simonmar at microsoft.com
Mon Nov 17 10:46:23 EST 2003
> On Tue, Nov 11, 2003 at 09:39:05AM -0000, Simon Marlow wrote:
> > Hmm, there is clearly a choice between having a signal spawn a new
> > thread or raise an asynchronous exception, and it's not at all clear
> > which is best.
> > But, since we can implement either using the other one, it doesn't
> > really matter too much which one is primitive.
> While either could be implemented in terms of the other, the choice of
> which to use for the default handlers will change the behavior of the
> program dramatically, simply because it determines whether
> bracket cleans up in the presense of signals.
So, essentially you're saying that BY DEFAULT, the behaviour should be
that certain signals raise an exception (in the main thread only)?
It's not clear to me that this should be the default behaviour. If it
is, you'd probably want a way to turn it off - the withSignals API
doesn't provide a way to turn it off, apart from 'block'.
I'd be much happier to just provide the tools for now; if it turns out
later that virtually everyone is beginning their programs with
'withSignal sigINT...', then we can possibly make it the default later.
> In darcs, I really have no interest in dealing with signals,
> I just want to
> make sure my temporary files are cleaned up even if the user
> hits ^C. If
> the default signal handler uses exceptions, this will happen for free.
> Currently, my only choice for the former purpose is to use
> something like
> I guess the problem is that as far as I can tell, there is no way to
> implement a "correct" bracket along with the existing POSIX signal
> implementation, since there's no way to find out what the
> current handler
> is, which means bracket can't install its own handler without
> messing up the current handler.
Hmm, I don't think I understand this. bracket is just fine as it is;
it's just the signal handler which needs to raise an exception, right?
More information about the Libraries