in reply to Re^4: Exiting a script with an 'infinitely looping' thread
in thread Exiting a script with an 'infinitely looping' thread

Due to Perl "safe signals", sleep is an uninteruptable opcode. Try it this way: 

#!/usr/bin/perl -w

use threads;
$SIG{"INT"}=\&sigInt;

my $thread=threads->create('test')->detach();

my $n = 100;
1 while --$n and sleep 1;

sub test { my $n = 100; 1 while --$n and sleep 1; }

sub sigInt { exit; }

[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.
"Too many [] have been sedated by an oppressive environment of political correctness and risk aversion."

Replies are listed 'Best First'.
Re^6: Exiting a script with an 'infinitely looping' thread
by ikegami (Patriarch) on Nov 24, 2008 at 16:21 UTC

    Due to Perl "safe signals", sleep is an uninteruptable opcode

    The docs and my observations disagree. 

    #!/usr/bin/perl
$\ = "\n";
$SIG{INT} = sub { print "SIGINT" };
print time;
sleep();  # Sleep forever
print time;

    [download]
    1227543323
SIGINT
1227543325

    [download]

    Safe signals means that the handler is only called after sleep returns, but sleep returns as soon as a signal is received.

    The behaviour differs in Windows, but then again, there are no signals in Windows.

[reply]
[d/l]
[select]
      The behaviour differs in Windows, ...

      Exactly. You know what I use...

      but then again, there are no signals in Windows.

      And yet: 

      C:\test>perl -wle"1 while 1"
Terminating on signal SIGINT(2)

C:\test>perl -wle"1 while 1"
Terminating on signal SIGBREAK(21)

      [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]

        I meant at the OS level. What you see is Perl's emulation of signals. And as there usually is with emulations, there are incompatibilities in the behaviour of the emulated signals. That it doesn't work in Windows has nothing to do with safe signals, and all to do with a flawed emulation of sleep.

[reply]
[d/l]
Re^6: Exiting a script with an 'infinitely looping' thread
by markseger (Beadle) on Nov 24, 2008 at 15:59 UTC
    I tried your code and it also produces the same warning. Could it be related to my version of perl? I tried both on an 5.8.0 and 5.8.5 and got the same results in both cases. I even tossed a print into the sigint handler to make sure it fired and also sleep 2 seconds before trying to exit in case I needed for the sleep in the thread to wake up. Still no luck. 
    # ./foo.pl
^C
A thread exited while 2 threads were running.

    -mark

[reply]

      Upgrade!

      Certainly upgrade your threads & threads::shared to the latest cpan versions. Using the versions in any of the distributions prior to 5.8.6 (and especially 5.8.0! Are you really still using that?), is just going to give you a world of grief and no support at all.

      I'd also suggest upgrading to either 5.8.6 or waiting a few more days until 5.8.9 is released.

      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 upgrade - no can do! I don't know if you ever heard of the performance monitoring tool collectl before - see http://collectl.sourceforge.net/. I'm working on some enhancements and I really need to support older versions of perl, especially since there are LOTS of users out there and I can't demand they upgrade their perl version. The thread code, which is pretty simplistic since I'm not doing anything really fancy with it, seems to be working very well except for that pesky warning.

        If detach doesn't work with older perls does that mean I have to resort to using a shared variable to tell the thread to exit? I'd really like to avoid doing that if possible.

        One other thought is that one typically runs collectl as a daemon with all the terminal I/O redirected to /dev/null so if this is really only a warning and the thread does get cleaned up, perhaps simply documenting that the message only occurs with older perl versions and can be safely ignored might be the ultimate solution.

        But wait, I just tried running the same code on a stock RHEL 5.1 system which is running perl 5.8.8 and it also produced the message, so either I need a newer perl version for the message to go away OR there is a bug in the sample that was posted.

        -mark

[reply]

In Section Seekers of Perl Wisdom