Re^2: removing all threads..

[BrowserUk]

in reply to Re: removing all threads..
in thread removing all threads..

Polling on a file is a ridiculous idea.

If there is any need to poll -- and there usually isn't -- a simple shared variable is far simpler to program and far safer.

[flexvault]

BrowserUk,

Okay...Ed

[Tommy]

I concur with this method, but I've found it difficult to do in the past without Threads::Shared which has some serious limitations. How else would you share a variable? I'm keenly interested in seeing your methodology...

As far as the OP's question goes, In the past I've pushed the result of a new thread call onto an array, where I reap all the children on exit by coursing through the array and either waiting on them or sending them a nasty signal if necessary. Threads are tricky business... Especially when you're refactoring someone else's older code where they used threads irresponsibly, or at least without regard to how they get reaped.

[BrowserUk]

but I've found it difficult to do in the past without Threads::Shared which has some serious limitations.

Hm. Seems simple enough to me?:

#! perl -slw
use strict;
use threads;
use threads::shared;

my $sem :shared;
sub tprint {
    lock $sem;
    print @_;
}

my $dieNow :shared = 0;
$SIG{INT} = sub {
    tprint 'sigint seen';
    $dieNow = 1;
    return;
};

sub thread {
    my $tid = threads->tid;
    my $delay = int rand 10;
    my $next = time + $delay;
    while( sleep 1 ) {
        last if $dieNow;
        redo unless time > $next;
        tprint "[$tid] ping";
        $next = time + $delay;
    }
    tprint "$tid] ending";
}

my @threads = map async( \&thread ), 1 .. 10;

sleep 1 until $dieNow;
$dieNow = 1;

$_->join for @threads;

Outputs:

C:\test>1007974
[3] ping
[9] ping
[1] ping
[3] ping
[2] ping
[4] ping
[3] ping
[1] ping
[9] ping
[5] ping
[3] ping
[6] ping
[10] ping
sigint seen
[3] ping
7] ending
2] ending
5] ending
8] ending
1] ending
9] ending
4] ending
6] ending
10] ending
3] ending

[Tommy]

browserUk++

I keenly (and painfully) remember getting segfault after segfault with threads::shared on distributed cluster of rhel 5 servers I had to work with about 6 months back. I eventually gave up and just used stock threads. The application was about 2K lines and I wasn't about to try to find out why threads::shared wouldn't work...everything looked fine, and I was following all the rules. What's more, I needed to share some very complex datastructures (I believe the real problem was exactly that, and it was an uncompromising requirement). I got around the segfaults by using a not-so-elegant fix (Storable::lock_store / Storable::lock_retrieve on a ramdisk). I'm not proud of that, but it worked and it's been running in production as a persistent service for worldwide venues going on several months now -- no memleaks, no segfaults, no problems. It had to be done to get it to work on the old rhel 5 platforms.

I chocked it up to having a perl that was too old when the same code ran fine on my own servers which had the most recent stable perl. I made a mental note that in the future I would need to be more careful with threads::shared (or avoid it entirely) when writing code that might need to run on legacy servers.

Just my own personal experience; YMMV

I appreciate the time you took in coding that example for me. I don't take it lightly that you freely gave your own valuable time to do that. Thank you.