in reply to Alarms with ActivePerl do not work properly

alarm comes from UNIX, and is based on a UNIX specific architechture, i.e. signals.

alarm does not work on the Activestate implementation of Perl on Windows, and that is well documented: in the ActiveState documentation "Windows quirks" Why doesn't signal handling work on Windows?".

There are also several nodes here: alarm not triggering SIGALRM on Windows 2003, Timeouts: Any alternative to alarm in Win32?, Re^2: alarm() on windows 2003, overview, Timeouts/timers on Win32 system. As perlport says "Don't count on signals or %SIG for anything.".

Some signals are implemented in the Microsoft C compilers, but only the absolute minimum to conform to the ANSI C standard. Those signals supported do not include SIGALRM.

Windows does have a rich timer API based around Waitable Timers, designed to be called from C/C++. See http://msdn.microsoft.com/en-us/library/ms687012(v=vs.85).aspx.
  • Comment on Re: Alarms with ActivePerl do not work properly

Replies are listed 'Best First'.
Re^2: Alarms with ActivePerl do not work properly
by BrowserUk (Patriarch) on Jan 13, 2011 at 09:00 UTC
    alarm does not work on the Activestate implementation of Perl on Windows,

    Really? Explain: 

    perl -E"eval{ $SIG{ALRM}=sub{die}; say time; alarm(10); sleep 20; };sa
+y time"
1294909100
1294909110

    [download]
    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]
[d/l]

      alarm "works" since (I think) 5.8. On Windows, it's simulated using a timer message (WM_TIMER), but I think that "unsafe signals" do not look at whether that timer message has been received. So an alarm call can only interrupt the Perl interpreter when it is in the runloop, and not when it spends time in XS (or a system call, or a database operation).

      The above is from memory - a closer look at win32_alarm in win32.c will likely be enlightening. It seems that alarm() could be made to "work" with unsafe signals (as far as unsafe signals can ever be called to "work") by having the WM_TIMER message trigger a callback, just like SIG_ALRM would under some unixish OS.

[reply]
        alarm "works" since (I think) 5.8.

        Yes. But I know this. Others apparently do not.

        It may not work well, but it does work in some fashion. And those time when it fails to work, aren't confined to AS versions.

        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]

        Note that WM_TIMER messages never result in an asynchronous call back. The message loop must be running and the 'queued' WM_TIMER message must be processed during the normal message loop polling for the call back function to be called. Also note that WM_TIMER messages are about the lowest of the low and will not get processed if there are any higher priority messages queued.

        None if this may be relevant to the topic under discussion, but is somewhat non-obvious and can be critical information in some circumstances (say he who has been bit in the past)!

        True laziness is hard work
[reply]
        Sorry, I'm obviously out of date. However the doc still says those things.
[reply]

In Section Seekers of Perl Wisdom