in reply to Exiting a script with an 'infinitely looping' thread

if I have a thread that never exists, what is the cleanest way to shut down the main script?

Three ways

  1. detach the never ending thread.

    When the main thread terminates, you won't get the warning.

  2. use a signal handler (to catch ^C) in the main thread to set a shared flag that the never ending thread monitors regularly, and then join the never ending thread from the signal handler before terminating.

    The disadvantage of this is that you need to ensure that and reads or attaches in your never-ending thread timeout occasionally, otherwise you will never check the shared flag until you receive something.

    That means using non-blocking IO for sockets.

  3. Faff around with per-thread signal handlers and use a signal handler in the main thread to send a kill signal to the never ending thread.

    More complicated and no real advantage over using a shared flag, as the thread handler won't respond to the kill signal if it is processing a blocking opcode like read or recv.

Which is more appropriate to your situation will depend upon how your app is currently coded?

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."
  • Comment on Re: Exiting a script with an 'infinitely looping' thread

Replies are listed 'Best First'.
Re^2: Exiting a script with an 'infinitely looping' thread
by markseger (Beadle) on Nov 24, 2008 at 15:00 UTC
    Ahhh... I do trap the ^C in my real script but had been lazy in my test script. As soon as I put the ^C in my test script it too complained!

    re detach thread - not sure how to do this but it sounds promising.

    re share flag - yes, I did realize that doing this I'd need to periodically wake up and check the flag, the only real negative here is that it would delay the time it takes for my script to shut down to as much as the 'wake up ' time, something I'd prefer to avoid.

    -mark

[reply]
      e detach thread - not sure how to do this but it sounds promising.

      See the pod for threads, but essentially where you currently do: 

      my $immortal = threads->create( ...);

      [download]

      doing 

      threads->create( ...)->detach;

      [download]

      is pretty much all there is to it. As the pod says:

      $thr->detach()

      Makes the thread unjoinable, and causes any eventual return value to be discarded. When the program exits, any detached threads that are still running are silently terminated.

      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]
[select]
        Time for some code and here's what I'm doing. I still get the message. Gotta be some thing silly (I hope) 
        #!/usr/bin/perl -w

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

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

while(1) { sleep 100; }

sub test { sleep 100; }

sub sigInt { exit; }

        -mark

[reply]

      A quick note: Detaching the thread doesn't cause it to exit cleanly, just silently. 

      #!/usr/bin/perl

use threads;

DESTROY { print "Destroyed\n" }

sub test {
   my $x = bless({});
   sleep() while 1;
}

$SIG{INT} = sub { exit };
my $thread = threads->create('test')->detach();
print("Press Ctrl-C to exit\n");
sleep();

      [download]

      If the thread exited cleanly, the above prints Destroyed. It doesn't.

[reply]
[d/l]
[select]

In Section Seekers of Perl Wisdom