in reply to Suppressing thread warnings

For starters, one way to silence the warning (since threads 1.33?) is to detach the threads. 

#!/usr/bin/perl

use threads;

threads->new(\&my_sub)->detach();
threads->new(\&my_sub)->detach();

sub my_sub {}

[download]
>perl script.pl

>

[download]

All it does is silence the warning. The underlying cause is still present, and it's quite serious. Your threads are being forcibly exited, doing no cleanup whatsoever. For example, the following code produces two empty files. 

#!/usr/bin/perl

use threads;

sub my_sub {
   open(my $fh, '>', "$0.".threads->tid() )
      or die;
   print $fh 'text';
   sleep(10);
}

threads->new(\&my_sub)->detach();
threads->new(\&my_sub)->detach();
sleep(2);

[download]

If you wish to run your program in the background, either do it from the shell 

$ script.pl &               unix

[download]
>start /b "" script.pl      Windows

[download]

or using something like: 

#!/usr/bin/perl

use strict;
use warnings;

BEGIN {
   # Move to running in background.
   if (!@ARGV || $ARGV[0] ne '--nobkg') {
      $SIG{CHLD} = 'IGNORE';
      require IPC::Open3;
      IPC::Open3::open3(
         '<&STDIN',
         '>&STDOUT',
         '>&STDERR',
         $^X, $0, '--nobkg', @ARGV
      );
      exit;
   }
}

use threads;

sub my_sub {
   open(my $fh, '>', "$0.".threads->tid() )
      or die;
   print $fh 'text';
   sleep(10);
}

my $thread1 = new threads(\&my_sub);
my $thread2 = new threads(\&my_sub);

$_->join() for $thread1, $thread2;

[download]

Replies are listed 'Best First'.
Re^2: Suppressing thread warnings
by BrowserUk (Patriarch) on Oct 11, 2008 at 01:31 UTC
    For starters, one way to silence the warning (since threads 1.33?) is to detach the threads.

    All very well if you *never* need to join the threads, but if, for example, you normally want to join them (to retrieve their results), but want to be able to terminate the process quickly without waiting for them if you receive a SIGTERM, you're stuffed.

    You can't even use the costly and nearly useless $thr->kill( <SIG> ) mechanism to pass on the signal, because it won't interupt IO, sort, etc. So, you're forced to either:

    • enable unsafe signals and risk crashing the entire process when you signal a thread.

    • use event-driven techniques--non-blocking IO; breaking code into iddy-biddy chunks--to ensure that your threads are periodically in a position to receive the signals.

      In which case you might as well just check a shared flag.

    • use _exit()

      Whilst it has risks, they are mostly mitigatable, and at least you control when things happen.

    These messages are entirely configurable and should be user controllable. Just another case of module authors deciding that they know better than module users.

    If you wish to run your program in the background, ...

    Where did that come from? Are you party to information not in the OP?

    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]

      All very well if you *never* need to join the threads, but if, for example, you normally want to join them (to retrieve their results), but want to be able to terminate the process quickly without waiting for them if you receive a SIGTERM, you're stuffed.

      My testing shows that exiting due to SIGTERM doesn't produce the warning. The process is simply killed. That means you can detach just before existing to silence the warning. Something like following should do the trick: 

      END { $_->detach() for threads->list(); }

      [download]

      If you wish to run your program in the background, ...

      Where did that come from? Are you party to information not in the OP?

      I got the idea that he wanted the threads to continue since he didn't end them. Obviously not the case. I should have provided assistance in ending his threads instead.

[reply]
[d/l]
[reply]

In Section Seekers of Perl Wisdom