Actually, structured exception handling (SEH) is the closest equivalent of UNIX synchronous signals (SIGSEGV, etc., those that are caused by the program itself) on Win32. As for asynchronous signals, there's APC (asynchronous procedure calls). (See https://msdn.microsoft.com/en-us/library/windows/desktop/ms6...)

I find Win32 vastly superior than UNIX in this area.

I don't think message queues and signals serve the same use case. Signal could be used for out-of-band communication.

You may be right, but in practice the syscall is so limited that I think many programs basically process the syscall as a message anyways, that using a messaging model may make more sense, and be easier to work with.

Someone correct me if I'm wrong, but because of the way the syscall callback operates, it could be interrupting threads at almost any stage. This makes executing the signal in a safe manner very difficult, and from the signal handler itself you can only run certain code. If i remember correctly, most signal handler implementations then get reduced to basically set some state and return, where the regular execution will then check for that state and react to it. Well, if your only going to process the signal during you main event loop anyways, then why not just exchange the information over a message queue, and send a message to the process when you want it to do something (ie reload configuration).

Well, from what I know, sometimes you just have to have out of band communication, check the discussion in the comment here: http://250bpm.com/blog:70

It sounds like a necessary use case to me. While most people would probably not use it, that doesn't invalidate its existence. Most people would probably not touch any low level code either way.