Re^4: I know that signal handling isn't working well on win32, but how bad is it?

Signals were a very, very bad design choice from the outset. *nix would be better off if they could be discarded. They have no good place in modern, multi-tasking, multi-threaded, multi-cored operating systems.

I do think, though, that signals have some merits over the event kinds of IPC. One of the strongest merit would be the fact that it doesn't require an event dispatch loop running to catch the signal. They are delivered directly to the handler whenever it occure and this could save some timing and codes if used well.

Comment on Re^4: I know that signal handling isn't working well on win32, but how bad is it?

Replies are listed 'Best First'.
Re^5: I know that signal handling isn't working well on win32, but how bad is it? by ikegami (Patriarch) on Mar 01, 2011 at 20:16 UTC
In practice, you can't really do much in an signal handler due to thread-safety issues. You end up needing an event dispatch loop to handle signals. For example, the only thing Perl ever does* in response to a signal is to set a flag. The signal is later handled by Perl's event dispatch loop. Even then, you end up library calls returning spuriously errors due to being interrupted, etc. * — Since 5.8.1, unless you disable safe signals.	[reply]
Re^5: I know that signal handling isn't working well on win32, but how bad is it? by BrowserUk (Patriarch) on Mar 01, 2011 at 21:36 UTC
I do think, though, that signals have some merits over the event kinds of IPC. See http://en.wikipedia.org/wiki/Signal_(computing)#Risks for the problems. Conversely, having a thread dedicated to servicing a message queue can be very simple, inexpensive and reliable. Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error. "Science is about questioning the status quo. Questioning authority". In the absence of evidence, opinion is indistinguishable from prejudice.	[reply]
Re^5: I know that signal handling isn't working well on win32, but how bad is it? by cdarke (Prior) on Mar 14, 2011 at 09:47 UTC
if used well Aye, there's the rub. You can only (safely) call certain reentrant functions in a signal handler, and in multi-threaded applications it is even worse - you don't know which thread is going to get interrupted. Further more, errno is a single shared global, and a handler's error could overwrite an existing value. See Advanced Programming in the UNIX Environment (2nd Edition, Stevens and Rago) section 10.6 for a discussion on this and other fun aspects of UNIX signals.	[reply]