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

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? Cheers, Simon