There is a strong difference between asynchronous signals (like SIGIO, SIGINT, etc..) and synchronous ones (SIGFPE, SIGSEG). I think only the second type should be treated as exceptions, since they are tied to a specific thread of execution. tying asynchronous signals to exceptions just because they are posted to the program in the same way seems wrong.

Good point: the synchronous signals should be treated as synchronous exceptions. The question raised by the initial post was whether the asynchronous signals should be treated as asynchronous exceptions; indeed there are cases when this is useful: in GHC the SIGINT signal is converted into an asynchronous exception which terminates the compiler. It is necessary to use an exception so that the compiler can clean up before exiting.

especially when we have concurrency. registering a callback, or even having a 'wait' like thing to blockingly wait for the next asynchronous signal would be ideal.

We already have the callback model, and it turns out you can implement pretty much anything else you want on top of it. There's no reason to restrict ourselves to just one API for signals.

we need some data type which contains the information in the 'siginfo_t' structure. then we can include this as a standard Exception type for use with synchronous signals.

Yes, we should do this too. Cheers, Simon