AGhoulDoingPerl has asked for the wisdom of the Perl Monks concerning the following question:

I know that signals are not working well on win32 port. But how bad is it?
I've read some article saying that it does still supported some, and I now wonder what signals are supported and what signals are not.

Particularly, I wonder about PIPE signal, which is triggered when you open a write pipe, but the other end of the pipe exits erruptly.
What would happen if the other end of the pipe got broken on win32 ports? Would it die out?, or fail silently?

Some of networking codes that I have been working on rely on the PIPE signal to be triggered at related event,
and that code is for the win32 environment. But if the $SIG{PIPE} is not working on win32, should I use eval on every piped writing?

Man, win32 sucks...:(

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

Replies are listed 'Best First'.
Re: I know that signal handling isn't working well on win32, but how bad is it?
by BrowserUk (Patriarch) on Feb 28, 2011 at 01:25 UTC

    sigpipe is not emulated on win32.


    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.
      OK... this strait things out for me. Thanks:)
Re: I know that signal handling isn't working well on win32, but how bad is it?
by cdarke (Prior) on Feb 28, 2011 at 09:20 UTC
    ERROR_BROKEN_PIPE is returned (test $^E) by the Win32 API when writing to a pipe where the reader died.

    Man, win32 sucks...:(

    No, it is just different. A wise man once said to me: "All operating system stink, they just have different smells".

    Signals are part of UNIX architechture. If you build an application which relies on a specific feature of an operating system then you cannot expect it to be portable. There are plenty of examples of Windows specific features that won't run on UNIX, but if you want portablity you have to avoid using them.

    Win32 has a powerful event system which you might like to investigate. See Win32::Event. And no, it is not portable.
      A wise man once said to me: "All operating system stink, they just have different smells".

      Windows smells a lot worse than UNIX. A lot worse.
        Not at all. The API is quite good. My only complaint is how it passes parameters to new processes. It's miserable, and it causes problems at every level.

        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.
Re: I know that signal handling isn't working well on win32, but how bad is it?
by ikegami (Patriarch) on Feb 28, 2011 at 01:31 UTC

    What would happen if the other end of the pipe got broken on win32 ports?

    I imagine it would return error EPIPE just like on unix if you were ignoring SIGPIPE. Didn't you try?

    But if the $SIG{PIPE} is not working on win32, should I use eval on every piped writing?

    Are you using IO functions that throw exceptions on error, then yes, but you have had to do that anyway.

    Man, win32 sucks...:(

    The only difference is whether the error is fatal or not by default. Having Windows choose to be not fatal by default is hardly a sucky decision.

      ... is hardly a sucky decision.
      Oh,well.. their decision would be fine, but win32 sucks as a whole, anyway :)

      Thanks for the reply.
        Could you give an example? I have the impression that you're not talking about Win32, but about Windows or Microsoft.