in reply to Re: Alarm and blocking I/O.
in thread Alarm and blocking I/O.

It seems replacing the default signal is the cause of the alarm failing to go off. I do not understand why, even this simple replacement causes the alarm to not go off.
$SIG{ALRM} = sub { die "alarm" };
Without it, the alarm does fire. Anyone can clarify why this is?

Replies are listed 'Best First'.
Re^3: Alarm and blocking I/O.
by BrowserUk (Patriarch) on May 29, 2010 at 22:49 UTC

    Sorry, my needs of alarm are relatively simple, which is just as well because as with anything signalish, simple is all you get on Win32.

    I've previously used the environment variable PERL_SIGNALS=unsafe, but recently discovered Perl::Unsafe::Signals which works for me and limits the scope. All I could do was pass on the information, as you're doing things I don't understand on a platform I don't use.


    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^3: Alarm and blocking I/O.
by expresspotato (Beadle) on May 29, 2010 at 22:18 UTC
    Huh... To anyone curious on how it is now working: Not checking for the file's existence before touching it and not touching it with utime.
    if (system(qq~ touch "$mount_server_check_path/mount_check"; ~)){ ...
    Perl :p