in reply to Re: IO::Socket::INET on win32
in thread IO::Socket::INET on win32

Yes, it's not "crashing" but exiting with an error, sorry. So if I'd publish portable code, what are best practices? Pepper the code with ioctl() if $^O =~ /win32/i or don't use IO::Socket::INET altogether, or use something else? I've seen POE calls ioctl() for versions less than 5.8, but calls $fh->blocking(0) otherwise... So that's incorrect, still use ioctl?

I've tried on 5.8 and 5.10, same thing.

Replies are listed 'Best First'.
Re^3: IO::Socket::INET on win32
by BrowserUk (Patriarch) on Dec 13, 2007 at 23:06 UTC
    Pepper the code with ioctl() if $^O =~ /win32/i ...

    Well, at the application level, probably the best thing you could do is override the IO::Socket constructor, strip the Blocking parameter on before instantiating the socket, and apply the ioctl() on the way out. Unfortunately, I don't think that will get you very far as I don't think the setting would be applied to sockets return by accept(), and then it starts getting messy.

    Of course, the best thing would be to apply/submit a patch to IO::Socket to enable the correct behaviour for Win32, but given the length of time that the 'fix' has been known, the fact that none of the experts hereabouts and elsewhere have applied such a patch could suggest that it is non-trivial.


    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.
      the fact that none of the experts hereabouts and elsewhere have applied such a patch could suggest that it is non-trivial

      Exactly. And that is what scares me most :(