Re^2: Alarms with ActivePerl do not work properly

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.

Comment on Re^2: Alarms with ActivePerl do not work properly Download Code

Replies are listed 'Best First'.
Re^3: Alarms with ActivePerl do not work properly by Corion (Patriarch) on Jan 13, 2011 at 09:28 UTC
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]
Re^4: Alarms with ActivePerl do not work properly by BrowserUk (Patriarch) on Jan 13, 2011 at 09:41 UTC
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]
Re^4: Alarms with ActivePerl do not work properly by GrandFather (Saint) on Jan 14, 2011 at 05:55 UTC
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]
Re^4: Alarms with ActivePerl do not work properly by Anonymous Monk on Jan 13, 2011 at 11:06 UTC
Sorry, I'm obviously out of date. However the doc still says those things.	[reply]