It's dumb that blasted message cannot be disabled! Same with the 'Free to wrong pool' developer diagnostic.

The simplest solution is:

use POSIX qw[ _exit ];

_exit( 123 );
[download]

But be aware that no destructors will be called, so if anything in your code requires cleanup, instigate it manually first. For example,

undef $objectNeedingCleanup;
_exit( 123 );
[download]

This did the job! Can you please explain what this actually does? I want to make sure it doesn't negatively affect my app. Note that it exists at the end of each run, so I'm not worried about garbage collection over a long period.

POSIX::_exit() calls your C-runtime to terminate the process. That bypasses all Perl contructs including END{} blocks and DESTROY() subroutines. Effectively, it completely bypasses Per's usual clean-up routines.

In doing so, it bypasses the perl-core code that detects that there are still threads running and produces the warning. But, it can also give problems if you are using modules that use DESTROY subs or END blocks to persist data, flush buffers and the like.

You can often cause object DESTROY methods to be called by undefing the handles, but I don't know of any way of forcing END blocks to be run without going through the full perl clean-up process.

In other words, use _exit() with caution.

---

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."

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]

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.

"Too many [] have been sedated by an oppressive environment of political correctness and risk aversion."

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.

use strict;
use warnings;
no warnings qw[threads];

use threads;

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

sub my_sub {}

exit; # needs explicit exit for reasons beyond me
[download]

Note that this will (I think) suppress all warnings related to threads. See warnings and perllexwarn and Category Hierarchy.

This didn't suppress this specific warning :(