Re^3: 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.

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.

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

Replies are listed 'Best First'.
Re^4: I know that signal handling isn't working well on win32, but how bad is it? by AGhoulDoingPerl (Sexton) on Mar 01, 2011 at 19:31 UTC
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.	[reply]
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]