in reply to Re^2: Suppressing thread warnings
in thread Suppressing thread warnings

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.

Replies are listed 'Best First'.
Re^4: Suppressing thread warnings
by BrowserUk (Patriarch) on Oct 11, 2008 at 07:07 UTC
[reply]
      Not a problem. Then the END block I posted handles it.
[reply]
[d/l]
        Then the END block I posted handles it.

        Sorry, I missed that. Was it a late addition?

        I agree that is a better work-around than POSIX::_exit(), but it is still a work-around that should not be necessary.

        Think of it this way. strict is optional. warnings are optional. The entire philosophy of Perl is permissive. Why should this one module buck that philosophy and decide that this warning is mandatory?

        I don't have a problem with it being on by default--indeed I use strict & warnings in everything I write; and I was a strong advocate for, and may even have had a significant influence in the default-on for these in Perl 6--but the user should be able to supress them through the normal no warnings (or $^W) mechanisms and not have to resort to such work-arounds.

        Similarly but even worse in some respects, are the Free to wrong pool messages, which are core developer diagnostics that, for the most part, the user programmer can do nothing about. There is one terse reference in the changes file for Digest::SHA to avoiding this message, but nothing your average application programmer is likely to be able to do much about, never mind the end user. So why do they have to see them?

        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]

In Section Seekers of Perl Wisdom